<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)
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
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
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/the upcoming/the upcoming version/ Succeeded: s/comfortable/uncomfortable/ Succeeded: s|https://github.com/w3c/clreq/issues?q=is%3Aissue+is%3Aopen+label%3A%E5%95%8F%E9%A1%8C%2Fquestion|https://github.com/w3c/i18n-activity/issues?q=is%3Aopen+is%3Aissue+label%3Atype-info-request+label%3Ahan| Present: addison xfq Richard plh dbarron sangwhan angel Chunming Found ScribeNick: addison Found ScribeNick: xfq Inferring Scribes: addison, xfq Scribes: addison, xfq ScribeNicks: addison, xfq Agenda: https://www.w3.org/International/wiki/2017TPACAgenda WARNING: No date found! Assuming today. (Hint: Specify the W3C IRC log URL, and the date will be determined from that.) Or specify the date like this: <dbooth> Date: 12 Sep 2002 People with action items: addison richard WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]