- From: r12a <ishida@w3.org>
- Date: Thu, 3 Jun 2021 16:10:34 +0100
- To: www-international@w3.org
- Message-ID: <026f11d7-a025-977d-628f-823e270b0ae2@w3.org>
https://www.w3.org/2021/06/03-i18n-minutes.html
– DRAFT –
Internationalization Working Group Teleconference
03 June 2021
[2]Agenda. [3]IRC log.
[2] https://lists.w3.org/Archives/Member/member-i18n-core/2021Jun/0000.html
[3] https://www.w3.org/2021/06/03-i18n-irc
Attendees
Present
Addison, Atsushi, Bert, fsasaki, Fuqiao, JcK, Richard
Regrets
-
Chair
Addison Phillips
Scribe
fsasaki
Contents
1. [4]Agenda Review
2. [5]Action Items
3. [6]Info Share
4. [7]RADAR Review
5. [8]manifest and localization
6. [9]Action Items
7. [10]Info Share
8. [11]AOB?
9. [12]Summary of action items
Meeting minutes
Agenda Review
Action Items
<addison> [13]https://www.w3.org/International/track/actions/
open
[13] https://www.w3.org/International/track/actions/open
addison: r12a, should I do your bidi related action as part of
my next editing round of string meta?
<addison> action-975?
<trackbot> [14]action-975: Addison Phillips to Update wiki on
i18n "considerations" sections and reply to sec/ping thanking
them -- due 2020-11-19 -- OPEN
[14] https://www.w3.org/International/track/actions/975
<addison> [15]https://www.w3.org/International/wiki/
OnInternationalizationConsiderations
[15] https://www.w3.org/International/wiki/OnInternationalizationConsiderations
addison: did work on this: updated wiki ...
… please have a look, comments are welcome
<addison> close action-975
<trackbot> Closed action-975.
addison: will close action
action-1017?
<trackbot> [16]action-1017: Addison Phillips to Send wpwg list
of specs that implement lang/dir -- due 2021-04-22 -- OPEN
[16] https://www.w3.org/International/track/actions/1017
pending
<addison> action-1024?
<trackbot> [17]action-1024: Addison Phillips to Review floating
times article for final publication -- due 2021-05-13 -- OPEN
[17] https://www.w3.org/International/track/actions/1024
addison: done, made some edits
… merged back in
<addison> [18]https://w3c.github.io/i18n-drafts/questions/
qa-floating-times.en
[18] https://w3c.github.io/i18n-drafts/questions/qa-floating-times.en
addison: does the group want to review this?
<addison> close action-1024
<trackbot> Closed action-1024.
addison: we did a wide review in the past
… I made only small edits
(no disagreement for publishing the doc, but table the doc for
now)
<addison> action-1030?
<trackbot> [19]action-1030: Atsushi Shimono to Ensure that a
summary of the ruby issue in english is forwarded to the
working group -- due 2021-06-03 -- OPEN
[19] https://www.w3.org/International/track/actions/1030
atsushi: sent out on Monday
<addison> close action-1030
<trackbot> Closed action-1030.
<addison> action-1031?
<trackbot> [20]action-1031: Addison Phillips to Document the
state of payment-request -- due 2021-06-03 -- OPEN
[20] https://www.w3.org/International/track/actions/1031
addison: pending, will work on it today
Info Share
xfq: W3C process will have a new version this year
… a new "note" track will be added
<xfq> [21]https://www.w3.org/Consortium/Process/
Drafts/#note-track
[21] https://www.w3.org/Consortium/Process/Drafts/#note-track
xfq: is separate from REC track, to avoid ambiguity
… above link shows the draft of the process
<atsushi> [22]all changes
[22] https://www.w3.org/Consortium/Process/Drafts/#changes-2020
addison: we are rechartering, so everything will be under
process 2021?
xfq: all specs will switch to new process once it is published
… patent policy is depending on the charter
addison: those are often linked
… there is probably not much impact on us
… a new version of respec will incooprate the stuff, I guess
RADAR Review
xfq: yes, should be transparent to all groups
<addison> [23]https://github.com/w3c/i18n-request/projects/1
[23] https://github.com/w3c/i18n-request/projects/1
addison: some new items
(addison going through the list)
atsushi: happy to make a review
… resource timing and user timing
addison: we will discuss this in 1 or 2 weeks
bert: interested to review dx profile
"dx profile negotiation" (data set negotation)
"Content Negotiation by Profile (dx-prof-conneg)"
bert: will have a look
manifest and localization
<addison> [24]https://github.com/w3c/manifest/issues/676
[24] https://github.com/w3c/manifest/issues/676
<addison> [25]https://www.w3.org/2021/05/
27-miniapp-minutes.html#t02
[25] https://www.w3.org/2021/05/27-miniapp-minutes.html#t02
<xfq> Open tracker issues for WAM: [26]https://github.com/w3c/
i18n-activity/
issues?q=is%3Aopen+is%3Aissue+label%3As%3Aappmanifest
[26] https://github.com/w3c/i18n-activity/issues?q=is:open+is:issue+label:s:appmanifest
addison: a search for what the best patterns should be, to
create a manifest for a web based app
… two common models are debated:
… a single file, contains different localization
… or: multiple manifest files, one per localization
… which do we recommend?
… what should be best practices for a space like this?
xfq: a third model would be:
… a file that contains not a whole manifest file, but some
localized strings
addison: a resource file attached to the manifest
xfq: correct
… each has pros and cons
… for web apps, they need to fetch multiple files, there is a
cost for fetching
… there may be potential duplications
… with a single file, it is difficult to modify
… if there are a lot of locales, the file is large, not easy to
manage
<JcK> +1
atsushi: separation is easier for distributed work
… quite easier to have separated files
… of course post processing could be used to create one file
… some apps may set english as default language
… or if some language is lacking, a value could be copied by
the processor from default language
<Zakim> fsasaki, you wanted to agree with atsuhi :)
<addison> felix: want to agree. in localization workflows, if
you have monolingual files it's easier
addison: agree ... there are several topics in here ...
… one has to do how language negotiation can occur ...
e.g., how do you select the localized resource ...
… that is there the default value comes into play
… you also want to reduce the number of fetches ...
… if you have a localized resource file, you want to know what
to get, based e.g. on language negotiation
… final consideration is the size
… if you do a lot of languages, you can have a huge manifest
file ...
… having dozens of locales would lead to a big file
jck: general idea of an index file
… and a default, and a bunch of URLs, doesn't that solve the
problem?
addison: would solve the problem
… lang neg. is then on the client, not on the server
… there is a couple of different models
… some manifests go into a zip file which forms an app
… if you bundle all in zip file you can have everything inside
… you do not fetch things, you just go inside the directory and
get what you want
… there was a directory structure with all kinds of stuff
… if you have a manifest, you want to fetch as less resources
as possible
… that would then be a multilingual file, or a file with links,
a list with what you need
jck: the latter has two fetches
addison: which is better than 50+
jck: and if you have thousands of resources, zip still needs a
lot of time to retrieve
atsushi: android jdk takes such an approach
… they use the "separate" model for storing localized string
addison: yes, and then everything comes in the zip file
… you download everything and read it
… which is also convenient for localization processes, as felix
mentioned
addison: how to move forward - should we contribute to the
thread?
"best practices for manifest files"
xfq: the problem is different from string metadata problem
addison: it is related to that problem
… since you will need string metadata in such situations
xfq: correct, and in such a file you can still have strings
with different languages and base direction
xfq: correct
r12a: people in that thread were starting to talk about many
different topics
… some examples seem to assume that you always know the
language of the document and the direction
… so this needs to be distinct from string metadata, and then
show how things work together
Action: addison: create skeleton of "best practices for
manifests"
<trackbot> Error creating an ACTION: could not connect to
Tracker. Please mail <sysreq@w3.org> with details about what
happened.
addison: once the skeleton is done, people can look at it for
further work on the doc
… anything else we want to do on the discussion thread?
Action Items
action-1032?
<trackbot> [27]action-1032: Richard Ishida to Propose text for
html 4814 (datalist find/string search) -- due 2021-06-03 --
OPEN
[27] https://www.w3.org/International/track/actions/1032
addison: how about the action on bidi keywords?
r12a: the glosarry is the place this should go to
<r12a> [28]https://w3c.github.io/i18n-glossary/#dfn-rtl
[28] https://w3c.github.io/i18n-glossary/#dfn-rtl
r12a: we have something in the glossar, not sure if that is
what you have in mind
<r12a> [29]https://w3c.github.io/i18n-glossary/#dfn-ltr
[29] https://w3c.github.io/i18n-glossary/#dfn-ltr
addison: would expect this together with some explanatory text
… a definition with usage
r12a: could go into an article or document
r12a: please do the edits you had in mind
addison: ok, will do
Info Share
<r12a> [30]https://w3c.github.io/i18n-glossary/
[30] https://w3c.github.io/i18n-glossary/
r12a: added more stuff to glossary, please have a look
<r12a> [31]https://w3c.github.io/i18n-drafts/pages/
documenting_gaps
[31] https://w3c.github.io/i18n-drafts/pages/documenting_gaps
r12a: looked at char mod, character essentials etc., this is
growing, keep an eye on it
r12a: this is also a reply to one of atsushi's github pull
requests
… mentions gap analysis pipeline
… tells you how to create a gap analysis document, via github
… and describes labels to use
… which is relevant for the pipeline
<addison> (notes that LDML is UTR35 in bibxml I believe)
r12a: if you do gap analysis, please have a look at this
… also, we had a discussion about 2021 process , cf. the note
track (mentioned by atsushi)
… we can also have "super notes"
… means: you have wide review and s.t. else
… and show that people reviewed it
… it then it gets the "w3c endorsed note" status
… relevant for various docs, e.g. "string meta"
… can be applied to existing docs, but needs evidence that
there has been a review
addison: so sort of like a REC, but without conformance etc.
… a bit like BCP in IETF
r12a: notes can be all kinds of shape in W3C
<xfq> [32]https://www.w3.org/Consortium/Process/Drafts/#memo
[32] https://www.w3.org/Consortium/Process/Drafts/#memo
r12a: it might be, that for our docs would be relevant for this
status
… name of the new document category is still under discussion
addison: would such a document go through the same gates for
publication?
<xfq> [33]https://www.w3.org/Consortium/Process/
Drafts/#revising-memo
[33] https://www.w3.org/Consortium/Process/Drafts/#revising-memo
r12a: not sure yet
<JcK> "Statements" are a step down the slippery slope from IETF
BCPs which can contain all of the categories you (Addison)
mentioned plus nearly pure rants
xfq: it seems that we can do editorial changes, but with
non-editorial changes, there is some processes
xfq: editorial means: fixing links, markup etc.
atsushi: note is similar to working draft
… wide review, AC review apply
addison: a bit like REC track, but not normative and without
implementation requirements
… might help us with some challenges we had in the past
… e.g. with regards to references to char mod norm
jck: useful for many cases
addison: is there a requirement during rechartering to list
work items with this target?
r12a: no
… process is not in place yet
addison: do you expect that to be in process 2021?
r12a: yes
<JcK> But problematic is not applied carefully and used very
conservatively
<addison> agenda
no more infoshare
AOB?
adjourned
Summary of action items
1. [34]addison: create skeleton of "best practices for
manifests"
Received on Thursday, 3 June 2021 15:12:35 UTC