- From: r12a <ishida@w3.org>
- Date: Thu, 22 Oct 2020 17:20:29 +0100
- To: www-international@w3.org
- Message-ID: <12857f4e-9963-1e07-505e-0a98abde2f3b@w3.org>
https://www.w3.org/2020/10/22-i18n-minutes.html
text extract follows:
- DRAFT -
Internationalization Working Group Teleconference
22 Oct 2020
[2]Agenda
[2] https://www.w3.org/wiki/I18N_2020_TPAC
Attendees
Present
Addison, Vainateya, Richard, Atsushi, Bert, xfq
Regrets
Felix, JcK
Chair
Addison Phillips
Scribe
Bert
Contents
* [3]Topics
1. [4]Agenda
2. [5]Action Items
3. [6]Radar
4. [7]Info Share
5. [8]Internationalization Considerations sections
6. [9]updating specdev
7. [10]Glossary
8. [11]AOB?
* [12]Summary of Action Items
* [13]Summary of Resolutions
__________________________________________________________
<addison> trackbot, prepare teleconference
<agendabot> addison, sorry, I did not recognize any agenda in
[14]https://www.w3.org/wiki/I18N_2020_TPAC
[14] https://www.w3.org/wiki/I18N_2020_TPAC
<scribe> scribe: Bert
Agenda
<atsushi> (trying to resolve low bandwidth... sorry.)
addison: agenda is open...
r12a: Talk about specdev?
addison: We also have our documents to talk about, ltli,
charmod, string-meta.
r12a: my action for string-meta may come up in specdev
discussion.
Action Items
<addison>
[15]https://www.w3.org/International/track/actions/open
[15] https://www.w3.org/International/track/actions/open
vainateya: Is there any ITS equivalent for JSON?
addison: Not aware of any. Maybe in JSON-LD. But probably
nothing equivalent to ITS. Related to string-meta, but not in
scope of string-meta itself.
<addison> action-895?
<trackbot> action-895 -- Addison Phillips to Respond to issue
4055 with i18n wg response about font fp asking justificiation
and adding various discussion points made in telecon -- due
2020-04-30 -- OPEN
<trackbot>
[16]https://www.w3.org/International/track/actions/895
[16] https://www.w3.org/International/track/actions/895
addison: Do I need to summarize?
... font fingerprinting, we talked about it with CSS on
Tuesday.
<xfq>
[17]https://github.com/w3c/csswg-drafts/issues/5421#issuecommen
t-709425330
[17] https://github.com/w3c/csswg-drafts/issues/5421#issuecomment-709425330
addison: Whether browsers should allow user-installed fonts.
hsivonen: Default should be to restrict, for privacy. An
explicit box to check for people to do otherwise.
r12a: It should be easy to use. Myles suggested a solution for
Safari that *technically* would work, if you are systems
engineer...
... Some Unicode Conf talks were about fonts and scripts.
... Many of the people involved moreover use mobile devices.
hsivonen: I don't have measurements, but bugs showed up.
Installing fonts on mobile is difficult. I wouldn't know how to
do it for Firefox, e.g.
addison: So I should put that into the issue somehow.
xfq: There is a pull request for the issue we discussed
Tuesday.
addison: More than one, actually.
<xfq> [18]https://github.com/w3c/csswg-drafts/pull/5625
[18] https://github.com/w3c/csswg-drafts/pull/5625
xfq: There is one that adds explanatory text, not about the
opt-in proposals.
<addison> action-958?
<trackbot> action-958 -- Addison Phillips to Write short
summary about "i18n considerations" sections for considering by
wg -- due 2020-10-01 -- OPEN
<trackbot>
[19]https://www.w3.org/International/track/actions/958
[19] https://www.w3.org/International/track/actions/958
<addison> close action-958
<trackbot> Closed action-958.
<addison> action-964?
<trackbot> action-964 -- Addison Phillips to Send issue 978 to
css and notify that our review is complete of css-cascade --
due 2020-10-15 -- OPEN
<trackbot>
[20]https://www.w3.org/International/track/actions/964
[20] https://www.w3.org/International/track/actions/964
<addison> close action-964
<trackbot> Closed action-964.
<xfq>
[21]https://github.com/w3c/csswg-drafts/issues/3029#issuecommen
t-712953765
[21] https://github.com/w3c/csswg-drafts/issues/3029#issuecomment-712953765
<addison> action-968?
<trackbot> action-968 -- Elika Etemad to Document dicussion of
logical vs. physical inheritance from i18n tpac meeting -- due
2020-10-27 -- OPEN
<trackbot>
[22]https://www.w3.org/International/track/actions/968
[22] https://www.w3.org/International/track/actions/968
<addison> close action-968
<trackbot> Closed action-968.
Radar
<addison> [23]https://github.com/w3c/i18n-request/projects/1
[23] https://github.com/w3c/i18n-request/projects/1
<r12a> CSS Custom Highlight API Module Level 1
<r12a>
[24]https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/
[24] https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/
r12a: There are a couple of FPWDs announced. Such as CSS
highlight API ^^
... I didn't have much time to read, but questions about
non-latin. It points to DOM spec for defining begin/end of a
range.
addison: It seems to be based on logical selection, good. But
it's a very early draft.
<xfq> [25]https://dom.spec.whatwg.org/#interface-range
[25] https://dom.spec.whatwg.org/#interface-range
hsivonen: So your question is if DOM code ranges can split?
addison: And if it splits surrogate pairs.
hsivonen: I don't think it can split grapheme clusters if the
selection is a range of text selected by the user. Don
<addison>
[26]https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/
#painting
[26] https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/#painting
<xfq> [27]https://dom.spec.whatwg.org/#ranges
[27] https://dom.spec.whatwg.org/#ranges
hsivonen: 't know about surrogate pairs.
addison: Should we put the draft on the Early Review list?
r12a: Yes
Info Share
Internationalization Considerations sections
<addison>
[28]https://www.w3.org/International/wiki/OnInternationalizatio
nConsiderations
[28] https://www.w3.org/International/wiki/OnInternationalizationConsiderations
addison: I wrote this ^^ recently. REcently, we've seen a spate
of new Foo Consideration sections, a11y, e.g.,
... I said we don't generally want an i18n considerations
section.
... Please read my text and react.
<hsivonen>
[29]https://encoding.spec.whatwg.org/#security-background"Secur
ity Background" instead of "Security Considerations"
[29] https://encoding.spec.whatwg.org/#security-background
<xfq> [30]https://www.w3.org/TR/json-ld/#internationalization
[30] https://www.w3.org/TR/json-ld/#internationalization
<xfq> [31]https://w3c.github.io/manifest/#internationalization
[31] https://w3c.github.io/manifest/#internationalization
[32]privacy considerations section example
[32] https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/#privsec
<r12a> [33]https://www.w3.org/TR/wot-security/#wot-privacy
[33] https://www.w3.org/TR/wot-security/#wot-privacy
r12a: Any examples of such sections?
<xfq> Security and privacy example
[34]https://w3c.github.io/sensors/#security-and-privacy
[34] https://w3c.github.io/sensors/#security-and-privacy
addison: it could also show up only if there are i18n issues.
But then do we put it at the end, or inline in the section
where it applies?
r12a: I think we should say we prefer inline, but for a certain
kind (not sure what), it's OK to make a separate section.
... If we have stuff inline, and also a section, is there harm
in that?
addison: No. But how easy is it to keep it comprehensive?
r12a: Is the section about process, about technical stuff?
... I think we should go and look at some sections to get a
clear idea of what is expected.
addison: I remember a case where I just went to the section
where the issue applied and fixed it right there.
... Do we generally want such a section, as part of the spec
template?
r12a: A list of all i18n issues and how they resolve is
probably not very useful. But a general text about things to
consider might be.
... E.g., for the text hightlight API we just discussed, it
could talk about the issue of placing pointers.
... But the technical content is not in this box here.
addison: If we don't fix an issue, there might have to be a
note. But otherwise: we already fixed it.
... OK to do this occasionally, but not in a formal way.
<r12a>
[35]https://w3c.github.io/i18n-drafts/techniques/shortchecklist
[35] https://w3c.github.io/i18n-drafts/techniques/shortchecklist
r12a: Could have the short review check list.
addison: But if somebody filled the check list and found
nothing, do we want to see the check list in the spec.
r12a: But they may have missed something in the list.
addison: It's our job to catch them.
hsivonen: Security and pricacy sections are often useful. But I
see the point of having i18n issues inline.
... As long as the issues are covered, it is editorial where
you put them.
... I don't have good arguments at the moment for how/when i18n
is different from security.
... Just my impression so far.
... Just yesterday I proposed a security warning that should be
placed inline.
... (In the encoding spec.)
r12a: I think it is more warnings, concerns, rather than
technical info.
hsivonen: An example is explaining if you use a spec
differently from intended, here is how it might go wrong.
r12a: I'd still like to see a few more examples first.
... I can go and look at
[36]https://github.com/w3c/webappswg/issues/25
[36] https://github.com/w3c/webappswg/issues/25
addison: So what is our recommendation?
r12a: I agree with you that inline is better and a section
without clear guidelines on what it contains is not useful. But
not disallowed.
addison: People can consider a section or we can require one.
Anybody for requiring?
r12a: Privacy and security people seem to want to require a
section. We should ask them why.
<addison> ACTION: addison: ping privacy/security about their
use of considerations sections
<trackbot> Created ACTION-970 - Ping privacy/security about
their use of considerations sections [on Addison Phillips - due
2020-10-29].
updating specdev
<r12a> [37]https://w3c.github.io/bp-i18n-specdev/
[37] https://w3c.github.io/bp-i18n-specdev/
r12a: While thinking about specdev: We don't want to duplicate
info. Maybe a single document with everything.
... The source is complex, in view of extracting the checklist.
... I think I can simplify it.
<addison>
[38]https://w3c.github.io/bp-i18n-specdev/#sec_lang_values
[38] https://w3c.github.io/bp-i18n-specdev/#sec_lang_values
r12a: E.g., look at 2.2
[39]https://w3c.github.io/bp-i18n-specdev/#sec_lang_values
... When you mouse over the rule, something could pop out.
[39] https://w3c.github.io/bp-i18n-specdev/#sec_lang_values
addison: I can use different scripting languages to extract
info. But want the different documents to the use the same
style.
r12a: We started using IDs that start with the name of the
section they are in.
<addison> [40]https://w3c.github.io/ltli/#ltli-bcp47-refer
[40] https://w3c.github.io/ltli/#ltli-bcp47-refer
addison: I expect ltli to merge into specdev after ltli has
been reviewed.
... We put the interesting information in documents, but not in
specdev.
r12a: Is that a goal, or just happens to be?
addison: So specdev would be just a checklist and all prose is
elsewhere?
<addison> [41]https://w3c.github.io/bp-i18n-specdev/#example-3
[41] https://w3c.github.io/bp-i18n-specdev/#example-3
r12a: Risk is documents that are too piecemeal, don't have the
overview.
... We can look at specdev and see where explanation is missing
and put in something short.
addison: E.g., looking at bidi in specdev: Should we have a
document about bidi?
r12a: I think we did have that in the past. I don't remember
why.
... Separate documents seems interesting.
... Specdev has the mustard and some explanation, but also
crossrefs and links to background info.
... The checklist is a clearing house for all the links.
addison: You mean like the purple blocks in specdev?
... If we added just some minimal prose, we could largely
automate the content.
<r12a>
[42]https://www.w3.org/International/techniques/developing-spec
s
[42] https://www.w3.org/International/techniques/developing-specs
addison: And if we have a new topic, we can write a new
document and specdev would link to it.
<xfq> Authoring HTML & CSS
[43]https://www.w3.org/International/techniques/authoring-html
[43] https://www.w3.org/International/techniques/authoring-html
r12a: We recommend people to use the checklist ^^ rather than
specdev.
... We generate the checklist from specdev. We could generate
both from a common source, in JSON, e.g.
... Say we split specdev into 10 or so documents, each with the
explanations, the mustard, links, etc.
addison: The documents are ltli, charmod, bidi (we have several
documents)...
... Those documents will be the home of the text.
r12a: Some of them are short.
<addison> [44]https://w3c.github.io/bp-i18n-specdev/#spec_n11n
[44] https://w3c.github.io/bp-i18n-specdev/#spec_n11n
addison: Yes, and specdev is like an index. But it is not an
index now.
<addison>
[45]https://w3c.github.io/i18n-drafts/articles/lang-bidi-use-ca
ses/index.en
[45] https://w3c.github.io/i18n-drafts/articles/lang-bidi-use-cases/index.en
addison: Specdev isn't an index now. E.g., that text (5.3.1)
should go into another document, charmod-norm.
<r12a> [46]https://w3c.github.io/typography/
[46] https://w3c.github.io/typography/
r12a: The question is if specdev should have explanatory text,
or just be an index.
<r12a>
[47]https://www.w3.org/International/techniques/developing-spec
s
[47] https://www.w3.org/International/techniques/developing-specs
r12a: We point people to the checklist. They only read one or
two paras of specdev when the checklist points them to it.
... Another thing for specdev: If the purple sections (the
links) are generated, they don't have to be collected at the
end.
addison: I'm thinking about how to bring the content over from
the other documents to specdev.
<r12a> [48]https://w3c.github.io/bp-i18n-specdev/#char_def
[48] https://w3c.github.io/bp-i18n-specdev/#char_def
r12a: We don't need to bring over all content, just the
mustard.
... If specdev is just an index, does it still have a role next
to the checklist?
xfq: What is the diff. between the checkist and specdev?
r12a: specdev has explanations in some places.
addison: And specdev is on /TR.
xfq: I more often use specdev, because of the explanations,
because I'm more used to document-stylem, and the checkist
isn't up to date with the editors' draft of specdev.
r12a: If specdev were just an index, would you stil use
specdev?
xfq: Probably not.
hsivonen: I find the document form easier. I need to expand all
topics in the checklist.
r12a: Several sections in specdev already have no explanation
in line and you need to go elsewhere already.
hsivonen: Every time you go back to the checklist, you need to
click the sections open again.
r12a: Idea is also that you read the explanation once or twice,
and after that, you only need the mustard.
addison: My concern at the moment is mostly how we flow content
in from other documents. Ideally that should be a button press.
... Having all info in specdev in one place is useful, but only
if the content is up to date.
... And it should not be just one person who is able to do the
edits.
<addison> [49]https://w3c.github.io/ltli/
[49] https://w3c.github.io/ltli/
r12a: Take LTLI: We find a section in specdev where to put the
topic. Then we extract the mustard from LTLI and copy it over.
None of the prose.
addison: I gave LTLI the same structure as specdev, so copying
is easy. Not completely automatic, but simple.
... The LTLI topics are in different places in specdev.
... The order of topics of specdev is for spec authors.
r12a: You can actually have the same mustard in two places in
specdev.
addison: As long as we keep the same structure for all our
docs, we can easily copy text.
r12a: With a JSON database, we can solve the update problem.
Specdev and the checklist would both be generated from the
same.
addison: And would LTLI also be updated from that?
r12a: Didn't consider that, but update something in the JSON
rather than edit the HTML of specdev.
Glossary
r12a: Would be good to have a single place to look up terms,
such as "ltr".
xfq: Where do the definitions come from? Our various documents?
r12a: Yes, as a starting point.
addison: Like the Unicode glossaries?
<r12a> [50]https://www.unicode.org/glossary/
[50] https://www.unicode.org/glossary/
xfq: The Unicode glossaries may already have definitions for
our terms.
r12a: Stil useful to have our own. They may be the same, be we
are free to make them different.
xfq: Would it be a respec document? A JSON file? Some other
form?
addison: Who wants to be the editor of the glossary?
r12a: I can put something together initially.
addison: I like us to have more documents, but they are a lot
of work and we just have two editors.
r12a: Yes, but if I take on glossary work, it is because it
make other writing easier. I can just point to already written
text.
... But you often cannot easily find the text.
addison: There are things I cannot help with. Should spread
around.
... Good if r12a sets things up, but we should get it to a
point that others can contribute.
AOB?
<addison> CSS: 7:30 Pacific (1430UTC)
<addison>
[51]https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/
0042.html
[51] https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0042.html
Note that they use Google Meet. May work best with Chrome.
Summary of Action Items
[NEW] ACTION: addison: ping privacy/security about their use of
considerations sections
Summary of Resolutions
[End of minutes]
Received on Thursday, 22 October 2020 16:20:36 UTC