[minutes] Internationalization TPAC meeting 2017-11-07


text version follows:

  - DRAFT -

          Internationalization Working Group 2017 TPAC (Tuesday)

07 Nov 2017


       [2] https://www.w3.org/International/wiki/2017TPACAgenda


           addison, xfq, Richard, plh, dbarron, sangwhan, angel,

           Addison Phillips

           addison, xfq


      * [3]Topics
          1. [4]Clreq update
      * [5]Summary of Action Items
      * [6]Summary of Resolutions

    <addison> ScribeNick: addison

    (starting at 9 AM today, first topic is Encoding spec to REC)

    <xfq> ScribeNick: xfq




       [8] https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#links

    [plh going through the slides]

    plh: this is something we spent the past months working on

    addison: /TR/foobar/latest is /TR/foobar in the past?

    plh: it depends on the group, for example, CSP's /latest is CSP
    2 instead of CSP 3
    ... /upcoming is the latest version of the highest level
    ... you decide if /TR/encoding/ means /TR/encoding/latest/ or

    r12a: so /TR/encoding/upcoming/ will not point to the WHATWG

    plh: yes, /TR/encoding/ed/ is designed for that

    r12a: I don't think we have a WD for Encoding...
    ... @@
    ... Do we have version numbers for our RECs?

    plh: The short answer is yes, but it's not in our process
    ... you have two models
    ... you can either branch at PR:
    ... or you branch at CR:

       [9] https://rawgit.com/w3c/spec-releases/gh-pages/releases-#1.svg
      [10] https://rawgit.com/w3c/spec-releases/gh-pages/releases-#2.svg

    addison: In an ideal world, we would not version Encoding.

    plh: See [11]https://www.w3.org/2017/11/versions-proposal.html
    ... The version exists, but they're done under the hood
    ... When you publish Encoding version 2, you can point
    /TR/encoding to the version 2

      [11] https://www.w3.org/2017/11/versions-proposal.html

    r12a: We may change what /TR/encoding goes to

    plh: We can refer to a WD normatively, e.g., Blob in FileAPI
    ... [12]https://www.w3.org/2017/11/versions-proposal.html is
    just a proposal now
    ... I plan to deploy it in December if people are happy about
    ... You can go to [13]https://www.w3.org/TR/encoding/ and click
    the Previous Version link
    ... you can see a red box
    ... I'll talk more about this tomorrow
    ... We're revamping the main /TR page
    ... You can go to main /TR page and choose which version is the
    upcoming version

      [12] https://www.w3.org/2017/11/versions-proposal.html
      [13] https://www.w3.org/TR/encoding/

    r12a: Why do we need to publish a REC?

    plh: Patent Policy, in addition to other reasons
    ... We can generate errata with specifically tagged commits/PRs
    on GitHub

    r12a: [14]https://www.w3.org/Guide/transitions should generate
    a transition request

      [14] https://www.w3.org/Guide/transitions

    plh: I was transfering tranistion requests to GitHub
    ... but distracted by other things
    ... will do that in the future

    r12a: We need to document the GitHub labels we're using

    plh: We have [15]https://w3c.github.io/issue-metadata.html

      [15] https://w3c.github.io/issue-metadata.html

    r12a: We have two labels for i18n

    plh: You can send a pull request for this page

    <plh> [16]https://github.com/w3c/w3c.github.io/

      [16] https://github.com/w3c/w3c.github.io/

    plh: For Encoding, we don't have the issue we have in HTML,
    since the two Encoding specs have the same content

    <addison> (break until 10:25)

    <addison> (next topic will be String-Metadata and the TAG

    <addison> (exuent plh)

    <addison> souq.com (use the flag to switch language)


      [17] https://github.com/w3ctag/design-reviews/issues/178

    <addison> [18]https://w3c.github.io/string-meta/

      [18] https://w3c.github.io/string-meta/


      [19] https://github.com/w3ctag/design-reviews/issues/178

    <addison> [20]https://w3c.github.io/string-meta/

      [20] https://w3c.github.io/string-meta/

    addison: If we have a time machine we would fix JSON
    ... but unfortunely we do not have one
    ... so we're providing a guideline for this

    r12a: It's not only JSON

    addison: I'm particularly concerned about JSON, because it's
    the data-interchange format
    ... people don't want to decorate every string, they want to
    put it in a file and override it sometimes

    dbaron: One thing that we've been talked a lot about is lang:
    and @@

    addison: you still have the ability to decorate a single string

    dbaron: We're writing "traditional JSON" with lang:, text:, and
    ... For faster lookup, @@

    addison: If you want a Japanese alternative of
    ... you would duplicate the object

      [21] https://w3c.github.io/string-meta/#baseExample

    <dbaron> "title": "Moby Dick"

    <dbaron> "title": [ {text: "Moby Dick", lang: "en" }, { text:
    "白鯨", lang: "ja" } ]

    <dbaron> (I'm omitting quotes at this point)

    <dbaron> "title": { en: {text: "Moby Dick", lang: "en" }, ja: {
    text: "白鯨", lang: "ja" } }

    <dbaron> "title": { en: {text: "Moby Dick" }, ja: { text: "白鯨"
    } }

    <addison> zh

    <addison> zh-Hans

    <addison> zh-hans-cn

    <addison> {text: Moby Dick dir:ltr}

    r12a: in some cases you may need arrays instead of objects

    dbaron: it does not need to be the core part of the

    <addison> deflang: en; title: Moby Dick

    <addison> deflang: en; title: { text: moby dick lang: en}

    <dbaron> with a default higher up, could do: "title": { en:
    "Moby Dick", ja: { text: "白鯨", lang: "ja" } }

    dbaron: The lookup table is not related to the language

    <dbaron> have to explain why "title": { en: {text: "Moby Dick"
    }, ja: { text: "白鯨" } } is bad because things can't be passed

    <sangwhan> [22]https://github.com/heycam/webidl/pull/358

      [22] https://github.com/heycam/webidl/pull/358

    <addison> item: [tag: Localizable, tag: Localizable...]

    sangwhan: This is the most interoperable way of doing this

    <addison> title: Moby Dick

    r12a: what's irritating me is that you have duplicated metadata
    ... in the default case (English), what would we do with option

    dbaron: The default thing is a trade-off

    addison: If you want to avoid send duplicated metadata you
    would want to strip them off

    dbaron: The default could just be a string or a decorated
    string if there's no need

    r12a: What's a decorated string?

    dbaron: { text: "白鯨", lang: "ja" }


      [23] https://github.com/w3ctag/design-reviews/issues/178

    <sangwhan> Search for "someAPI({"

    dbaron: Of the two options Domenic commented on, we're
    uncomfortable with the first one in JSON
    ... It's worth providing strong advice, while keeping reasons
    why we're rejecting other options

    addison: That makes sense

    dbaron: I think the preferred option should probably have more
    ... and other options have less text

    addison: We have no implementation experience about this

    <dbaron> - advantages and disadvantages of defaulting

    <dbaron> - JSON vs. WebIDL

    <dbaron> - what about lookup-a-language cases (arrays,

    addison: What we should do is that we add a "recommended
    approach" section after the intro section

    r12a: In some cases you may be dealing with markup strings

    dbaron: I think the recommended way from the i18n WG is using
    markup as much as possible

    r12a: @@
    ... You need to parse the HTML in some cases
    ... If you have a string, you can use decorated string
    ... If you have markup, you use attributes

    addison: in a weaker recommendation, you could provide a
    default language with undecorated string

    r12a: The en: and ja: is an optimization thing

    <addison> ACTION: addison to update string-meta with newly
    planned recommendations and then notify dbaron@ and sangwhan@
    by name in github tag issue

    <trackbot> Created ACTION-680 - Update string-meta with newly
    planned recommendations and then notify dbaron@ and sangwhan@
    by name in github tag issue [on Addison Phillips - due

    <addison> (exuent dbaron and sangwhan)

    <addison> (topic clreq)

Clreq update

    angel: status update about clreq
    ... Fuqiao has some FTE related to i18n
    ... clreq work is ongoing
    ... we're expecting another WD by the end of the year

    r12a: we have a bunch of questions that needs answer in clreq



    angel: the editors are interested in keep doing the work


      [25] https://www.w3.org/TR/2017/WD-typography-20170209/

    angel: if you need quick answers you can to prioritize them

    r12a: there are also Mongolian issues
    ... what we're doing now is to do the gap analysis first

      [26] https://github.com/w3c/i18n-activity/issues?utf8=✓&q=is:open 
is:issue label:type-info-request label:mongolian



    r12a: first, find gaps
    ... second, go to the *lreq document and write stuff about that
    ... third, reach out to the browser developers

    angel: do we have contacts in the browser companies?

    r12a: yes, we have.
    ... If we go with Tibetan and Mongolian, we should go with the
    gap analysis way first, instead of writing a book

    angel: I agree



    r12a: We have categorization of international layout features
    ... Liang Hai came up with an alternative proposal of Mongolian
    encoding in a Unicode Consortium conference
    ... The important thing is we have to document what the rules

    angel: Is the encoding issue related to W3C? I thought we only
    focus on the layout part.

    r12a: You can't really use Mongolian on the Web unless you
    solve this problem
    ... the CSS people, the TTML people, etc. would like to know
    what Mongolian people needs

    angel: Inner Mongolian and "Outer Mongolian" people have
    different opinions about this issue

    r12a: not that many differences, though
    ... Would you like me to set up a task force?

    angel: ok

    <addison> ACTION: richard to set up mongolian task force

    <trackbot> Created ACTION-681 - Set up mongolian task force
    framework [on Richard Ishida - due 2017-11-14].

    angel: we're doing work locally for now
    ... about Tibetan, we have some text now
    ... but not much

    r12a: The issue is that it's not written by a group of Tibetan
    ... might not be ready for FPWD without review
    ... We also need to do the translation

    angel: English is a major issue for them
    ... it's a much larger issue for them than for the clreq folks

    r12a: Also need to explain the gap analysis framework to them
    ... and communicate with them regularly

    angel: About Uyghurs, the national standard has been published

    r12a: I know some Uyghurs experts

    <addison> ACTION: richard to contact uighur contacts and send
    information to start conversation

    <trackbot> Created ACTION-682 - Contact uighur contacts and
    send information to start conversation [on Richard Ishida - due

    angel: Do they understand Chinese?

    r12a: They're not Chinese, but they understand Chinese

    <addison> (lunch)

    <Chunming> Gap analysis:

      [29] https://w3c.github.io/typography/gap-analysis/

    <addison> (end of lunch)

    <addison> [30]http://aphillips.github.io/charmod-norm/

      [30] http://aphillips.github.io/charmod-norm/

    <addison> change example for turkic to case fold only (lower
    case basically)

    <addison> change Unicode C+S and C+F to simple and full

    <addison> make links from algo to sectino about that

    <addison> move the note about expansion of includes/escapes to
    3.3 where it belongs

    <addison> add normalization as an option to algo

    <addison> change step 3 to include case sensitive in the
    instruction, not as a fold option

    <addison> remove step 4 if no one objects

Summary of Action Items

    [NEW] ACTION: addison to update string-meta with newly planned
    recommendations and then notify dbaron@ and sangwhan@ by name
    in github tag issue
    [NEW] ACTION: richard to contact uighur contacts and send
    information to start conversation
    [NEW] ACTION: richard to set up mongolian task force framework

Summary of Resolutions

    [End of minutes]

Received on Wednesday, 15 November 2017 15:51:32 UTC