– DRAFT –
Internationalization Working Group Teleconference

Agenda Review

Action Items

<addison> 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> action-975: Addison Phillips to Update wiki on i18n "considerations" sections and reply to sec/ping thanking them -- due 2020-11-19 -- OPEN

<addison> 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> action-1017: Addison Phillips to Send wpwg list of specs that implement lang/dir -- due 2021-04-22 -- OPEN

pending

<addison> action-1024?

<trackbot> action-1024: Addison Phillips to Review floating times article for final publication -- due 2021-05-13 -- OPEN

addison: done, made some edits
… merged back in

<addison> 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> 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

atsushi: sent out on Monday

<addison> close action-1030

<trackbot> Closed action-1030.

<addison> action-1031?

<trackbot> action-1031: Addison Phillips to Document the state of payment-request -- due 2021-06-03 -- OPEN

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> 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> all changes

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> 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> https://github.com/w3c/manifest/issues/676

<addison> https://www.w3.org/2021/05/27-miniapp-minutes.html#t02

<xfq> Open tracker issues for WAM: https://github.com/w3c/i18n-activity/issues?q=is%3Aopen+is%3Aissue+label%3As%3Aappmanifest

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> action-1032: Richard Ishida to Propose text for html 4814 (datalist find/string search) -- due 2021-06-03 -- OPEN

addison: how about the action on bidi keywords?

r12a: the glosarry is the place this should go to

<r12a> 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> 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> https://w3c.github.io/i18n-glossary/

r12a: added more stuff to glossary, please have a look

<r12a> 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> 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> 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