Internationalization Working Group 2017 TPAC (Tuesday) -- 07 Nov 2017

<addison> ScribeNick: addison

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

<xfq> ScribeNick: xfq

<plh> https://w3c.github.io/spec-releases/milestones/?cr=2018-01-11&noFPWD=true

<plh> 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 /TR/encoding/upcoming/

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

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 currently.
... you have two models
... you can either branch at PR: https://rawgit.com/w3c/spec-releases/gh-pages/releases-%231.svg
... or you branch at CR: https://rawgit.com/w3c/spec-releases/gh-pages/releases-%232.svg

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

plh: See 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

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

plh: We can refer to a WD normatively, e.g., Blob in FileAPI
... 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 this
... You can go to 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

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: https://www.w3.org/Guide/transitions should generate a transition request

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 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> 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 discussion)

<addison> (exuent plh)

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

<addison> https://github.com/w3ctag/design-reviews/issues/178

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

<addison> https://github.com/w3ctag/design-reviews/issues/178

<addison> 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 dir:
... For faster lookup, @@

addison: If you want a Japanese alternative of https://w3c.github.io/string-meta/#baseExample
... you would duplicate the object

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

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

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

<sangwhan> 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 2?

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" }

<sangwhan> 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 text
... 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, dictionaries)?

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 2017-11-14].

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

https://github.com/w3c/i18n-activity/issues?q=is%3Aopen+is%3Aissue+label%3Atype-info-request+label%3Ahan

angel: the editors are interested in keep doing the work

<Chunming_> 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
... https://github.com/w3c/i18n-activity/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20label%3Atype-info-request%20label%3Amongolian%20
... what we're doing now is to do the gap analysis first

<Chunming_> https://w3c.github.io/typography/gap-analysis/language-matrix.html

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

<addison> https://github.com/w3c/i18n-discuss/wiki/Analysing-support-for-text-layout-on-the-Web

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 are

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 framework

<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 people
... 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 2017-11-14].

angel: Do they understand Chinese?

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

<addison> (lunch)

<Chunming> Gap analysis: https://w3c.github.io/typography/gap-analysis/

<addison> (end of lunch)

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

<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

- DRAFT -

Internationalization Working Group 2017 TPAC (Tuesday)

07 Nov 2017

Attendees

Contents

Clreq update

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output