Meeting minutes
<addison> trackbot, prepare teleconference
Agenda
MiniApp I18N design discussion
<xfq> https://
<xfq> https://
addison: Welcome to the miniapp people. Fuqiao, can you intro the topic?
xfq: We discussed issues last week, mostly about manifest: bidi, localization
… addison filed an issue about how to make apps in multiple languages.
… Can miniapp editors explain the i18n architecture of miniapps?
addison: Esp. the design goals. The bigger picture may help us understand better and give more targeted comments.
… How does a miniapp author make an app localized in multiple languages?
yongjing_zhang: Thanks for the comments and issues.
… We haven't thought deeply aboiut i18n issues.
… I didn't understand the the full question at first.
… The design is not complete. We did think a bit. We first focused on localization in-app.
… There would be a number of JSON files in the package, for the pages inside the app.
… We did not think about localizing the manifest.
… For the time being requires separate app for each language.
… We could think about localizing the manifest to have localized apps in a single package.
… I'm editor, but I cannot speak for the whole group, as we haven't discussed it. So this is just personal.
… Martin and I discussed a bit. Could have several manifests and a single "main" manifest, that links to the others.
addison: I think you have to think as an app author and what the maintenance would be like. My company typically makes apps in some 30-35 languages.
… Have to consider thinks like default size, default orientation.
… Doing the same 35 times becomes hard to maintain.
… How can you recycle the settings across multiple files.
… But maybe these can files can generated, in which case it is less of an issue.
… Separete packages for each language is also hard for users, who have to pick among 30 apps and maybe switch apps just to change language.
yongjing_zhang: Thanks for those comments. We maybe don't have to duplicate things in all manifests. But just initial thoughts for now.
… We will discuss in the group. Appreciate more guidance.
martin: We have been in touch with WebApps WG to be compatible with manifests.
… We haven't thought about solutions for localize the metadata in the manifest yet.
<Zakim> addison, you wanted to talk about language negotiation
martin: But we are interested in the issue and will discuss it.
addison: Language Negotiation may be something else to think about.
… You may be able to leave it to frameworks and not be precise about it, but good to say something.
… Imagine getting a request for Mexican Spanish which you don't have, but have a close match.
… Think about infrastructure.
yongjing_zhang: The miniapp design comes from different existing implementations in the Chinese market. We are trying to find a common solution. Different styles. Android style and others.
addison: You may not have to decide the implementation details. But you probably need to think about a common infrastructure, e.g., a common attribute for the locale, that app authors can use. There may be more happening at run time that you don't have to specify.
… Get to a standard that is interoperable. Otherwise not really a standard.
yongjing_zhang: We'll discuss. I imagine it will be hard.
addison: What do you want next? Come back and discuss here? Discuss via GitHub?
yongjing_zhang: After a discussion in the group and some deeper understanding we'll come to you for more comments on a proposal.
<xfq> https://
r12a: We talked about localization. But I had the impression there was also a question about applying different directions to strings within a single app.
… There is a way to declare a direction at the top level in the manifest. But what if a single app contains strings in two languages?
yongjing_zhang: We should address the two issues together, the localization and the two languages in one app.
r12a: Specifying per language not enough. Have to specify it per string.
… Also each string may need a language, apart from the single toplevel language.
addison: We generally think that is a requirement: top-level lang and direction and also per-string language and direction.
… Maybe a common structure for each string that includes the text, the direction and a language.
r12a: It is a good idea to have a top-level lang and direction, and the possibility to override it for a particular string.
… Language may affect various things: choosing the font, line wrapping...
yongjing_zhang: We will note it and discuss.
fsasaki: It's a typical problem for packaging. Do we have existing examples we can point to?
addison: There are examples, maybe in Android or iOS. I don't have a standard example off the top of my head.
<fsasaki> https://
<xfq> i18n issues in WAM: https://
<addison> https://
r12a: Ditto. But let me put a link to string-meta.
<r12a> https://
<xfq> (mostly localization issues rather than string-meta issues)
r12a: Ir is probably a good idea for us to look for examples...
David: When taking a multi-file approach, it is is good to look at a way to only encode the differences. A bit like the way CSS rules override other rules.
martin: App manifest only declares a top level language now.
<xfq> https://
r12a: Maybe Ivan can help, Publication manifest for EPUB has similar things,
yongjing_zhang: This seems not just related to miniapp, but also webapp. We should look for a common solution.
yongjing_zhang: Thanks for your input. We need input from experts.
addison: I'm always ready to schedule a telcon, even if timezones may be difficult.
Case folding
Bert: r12a's suggestion to do NFD and casefold, without NFC, might work, I think.
addison: I've been thinking about that as well.
… But Unicode specifies it the other way.
… I tried some code. too.
… And why does Unicode specify it like that?
r12a: Normalize first and then case-fold and then normalize: that works. But I think I cocluded a few months ago that NFD and case-fold only work, too.
addison: The subscript iota is the difficult case.
… We would look for cases.
r12a: I think doing NFD first "levels the playing field".
addison: So why does UNicode specify NFC?
… Maybe doing NFC at the end is just to make it nice.
r12a: I think I did something in Uniview... Could run the tables through the algo and see if they are different.
addison: I did that. I cannot think of combining marks that case-fold. I may write to Unicode to ask.
Action: addison: check TUS and if necessary ping Unicode folks about D145 normalization case fold ordering questions
<trackbot> Created ACTION-989 - Check tus and if necessary ping unicode folks about d145 normalization case fold ordering questions [on Addison Phillips - due 2021-01-21].
COGA icon review
<r12a> https://
<addison> https://
r12a: Lisa raised the issue in the i18n repo and somebody started answering there. So I updated the boilerplate text to make it clearer what the expected process is.
xfq: Yes, people are aware now.
r12a: The issue^^^ shows the things I noticed about the icons.
addison: Seems they are trying to give a kind of best practice, not standardize the icons. Seems to be based a lot on using metaphors.
David: Several concepts involve hands and gestures, which may be cultural.
addison: Not sure how to advise them.
… What shall we do? You want to send comments to them?
r12a: I can add text to my issue and send that.
addison: Any other opinions?