- From: r12a <ishida@w3.org>
- Date: Thu, 14 Jan 2021 16:34:15 +0000
- To: www-international@w3.org
- Message-ID: <bbf6d25b-a112-63a6-d24c-de02dc1a3119@w3.org>
https://www.w3.org/2021/01/14-i18n-minutes.html
===
summary
• MiniApp discussion with invited guests. Need to consider an
architectural strategy to support localisation of manifests. Need to
also create a mechanism that allows language and direction assignments
to be overridden on a string by string basis, where needed, within a
single manifest. The i18n WG should begin compiling a list of example
specs that have already dealt with this. MiniApps folks will discuss
this further in their group, and may come to i18n again for help.
• Case folding. We need to establish whether normalisation is needed on
both sides of case folding, or whether NFD+Case-fold is sufficient.
• COGA icon review. Group reviewed comment on proposed icons and agreed
to send.
===
text version follows:
– DRAFT –
Internationalization Working Group Teleconference
14 January 2021
[2]Agenda. [3]IRC log.
[2] https://lists.w3.org/Archives/Member/member-i18n-core/2021Jan/0002.html
[3] https://www.w3.org/2021/01/14-i18n-irc
Attendees
Present
Addison, atsushi, Bert, fsasaki, Fuqiao, JcK, Martin
Alvarez, martin_alvarez, Richard, Wangzitao (Miniapp),
Yongjing Zhang (Miniapp)
Regrets
-
Chair
Addison Phillips
Scribe
Bert
Contents
1. [4]Agenda
2. [5]MiniApp I18N design discussion
3. [6]Case folding
4. [7]COGA icon review
5. [8]AOB?
6. [9]Summary of action items
Meeting minutes
<addison> trackbot, prepare teleconference
Agenda
MiniApp I18N design discussion
<xfq> [10]https://github.com/w3c/i18n-activity/
issues?q=is%3Aissue+is%3Aopen+label%3As%3Aminiapp
[10] https://github.com/w3c/i18n-activity/issues?q=is:issue+is:open+label:s:miniapp
<xfq> [11]https://github.com/w3c/miniapp/issues/149
[11] https://github.com/w3c/miniapp/issues/149
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> [12]https://github.com/w3c/miniapp/issues/106
[12] https://github.com/w3c/miniapp/issues/106
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> [13]https://www.w3.org/TR/appmanifest/
[13] https://www.w3.org/TR/appmanifest/
<xfq> i18n issues in WAM: [14]https://github.com/w3c/manifest/
issues?q=is%3Aopen+is%3Aissue+label%3Ai18n-tracker
[14] https://github.com/w3c/manifest/issues?q=is:open+is:issue+label:i18n-tracker
<addison> [15]https://w3c.github.io/string-meta/
[15] https://w3c.github.io/string-meta/
r12a: Ditto. But let me put a link to string-meta.
<r12a> [16]https://w3c.github.io/string-meta/
[16] https://w3c.github.io/string-meta/
<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> [17]https://w3c.github.io/pub-manifest/
[17] https://w3c.github.io/pub-manifest/
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> [18]https://github.com/w3c/i18n-activity/issues/1008
[18] https://github.com/w3c/i18n-activity/issues/1008
<addison> [19]https://www.w3.org/TR/coga-usable/#summary
[19] https://www.w3.org/TR/coga-usable/#summary
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?
AOB?
Summary of action items
1. [20]addison: check TUS and if necessary ping Unicode folks
about D145 normalization case fold ordering questions
Minutes manually created (not a transcript), formatted by
[21]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).
[21] https://w3c.github.io/scribe2/scribedoc.html
Received on Thursday, 14 January 2021 16:34:21 UTC