[minutes] Internationalization telecon 2021-06-03


            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


           Addison, Atsushi, Bert, fsasaki, Fuqiao, JcK, Richard


           Addison Phillips



     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/

      [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/

      [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


    <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


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

      [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

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

      [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/

      [25] https://www.w3.org/2021/05/27-miniapp-minutes.html#t02

    <xfq> Open tracker issues for WAM: [26]https://github.com/w3c/

      [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

    <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

    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

    addison: how to move forward - should we contribute to the

    "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

    <trackbot> Error creating an ACTION: could not connect to
    Tracker. Please mail <sysreq@w3.org> with details about what

    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


    <trackbot> [27]action-1032: Richard Ishida to Propose text for
    html 4814 (datalist find/string search) -- due 2021-06-03 --

      [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/

      [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
    … 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
    … name of the new document category is still under discussion

    addison: would such a document go through the same gates for

    <xfq> [33]https://www.w3.org/Consortium/Process/

      [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

    <addison> agenda

    no more infoshare



Summary of action items

     1. [34]addison: create skeleton of "best practices for

Received on Thursday, 3 June 2021 15:12:35 UTC