- From: r12a <ishida@w3.org>
- Date: Wed, 15 Nov 2017 15:44:48 +0000
- To: www International <www-international@w3.org>
https://www.w3.org/2017/11/07-i18n-minutes.html
text version follows:
- DRAFT -
Internationalization Working Group 2017 TPAC (Tuesday)
07 Nov 2017
[2]Agenda
[2] https://www.w3.org/International/wiki/2017TPACAgenda
Attendees
Present
addison, xfq, Richard, plh, dbarron, sangwhan, angel,
Chunming
Regrets
Chair
Addison Phillips
Scribe
addison, xfq
Contents
* [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
<plh>
[7]https://w3c.github.io/spec-releases/milestones/?cr=2018-01-1
1&noFPWD=true
[7]
https://w3c.github.io/spec-releases/milestones/?cr=2018-01-11&noFPWD=true
<plh>
[8]https://www.w3.org/2017/Talks/tpac-slides/plenary-project/#l
inks
[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
/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:
[9]https://rawgit.com/w3c/spec-releases/gh-pages/releases-%231.
svg
... or you branch at CR:
[10]https://rawgit.com/w3c/spec-releases/gh-pages/releases-%232
.svg
[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
this
... 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
discussion)
<addison> (exuent plh)
<addison> souq.com (use the flag to switch language)
<addison>
[17]https://github.com/w3ctag/design-reviews/issues/178
[17] https://github.com/w3ctag/design-reviews/issues/178
<addison> [18]https://w3c.github.io/string-meta/
[18] https://w3c.github.io/string-meta/
<addison>
[19]https://github.com/w3ctag/design-reviews/issues/178
[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
dir:
... For faster lookup, @@
addison: If you want a Japanese alternative of
[21]https://w3c.github.io/string-meta/#baseExample
... 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
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> [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
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>
[23]https://github.com/w3ctag/design-reviews/issues/178
[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
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
[24]https://github.com/w3c/i18n-activity/issues?q=is%3Aopen+is%
3Aissue+label%3Atype-info-request+label%3Ahan
[24]
https://github.com/w3c/i18n-activity/issues?q=is:open+is:issue+label:type-info-request+label:han
angel: the editors are interested in keep doing the work
<Chunming_>
[25]https://www.w3.org/TR/2017/WD-typography-20170209/
[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
...
[26]https://github.com/w3c/i18n-activity/issues?utf8=%E2%9C%93&
q=is%3Aopen%20is%3Aissue%20label%3Atype-info-request%20label%3A
mongolian%20
... 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
<Chunming_>
[27]https://w3c.github.io/typography/gap-analysis/language-matr
ix.html
[27]
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>
[28]https://github.com/w3c/i18n-discuss/wiki/Analysing-support-
for-text-layout-on-the-Web
[28]
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:
[29]https://w3c.github.io/typography/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
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
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:45:07 UTC