Internationalization Working Group Teleconference -- 22 Oct 2020

<addison> trackbot, prepare teleconference

<agendabot> addison, sorry, I did not recognize any agenda in 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> 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> 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> 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> 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> 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> https://www.w3.org/International/track/actions/964

<addison> close action-964

<trackbot> Closed action-964.

<xfq> 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> https://www.w3.org/International/track/actions/968

<addison> close action-968

<trackbot> Closed action-968.

Radar

<addison> https://github.com/w3c/i18n-request/projects/1

<r12a> CSS Custom Highlight API Module Level 1

<r12a> 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> 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> https://www.w3.org/TR/2020/WD-css-highlight-api-1-20201022/#painting

<xfq> 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> 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> https://encoding.spec.whatwg.org/#security-background"Security Background" instead of "Security Considerations"

<xfq> https://www.w3.org/TR/json-ld/#internationalization

<xfq> https://w3c.github.io/manifest/#internationalization

privacy considerations section example

<r12a> https://www.w3.org/TR/wot-security/#wot-privacy

r12a: Any examples of such sections?

<xfq> Security and privacy example 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> 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 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> 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> https://w3c.github.io/bp-i18n-specdev/#sec_lang_values

r12a: E.g., look at 2.2 https://w3c.github.io/bp-i18n-specdev/#sec_lang_values
... When you mouse over the rule, something could pop out.

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> 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> 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> 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 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> 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> 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> https://w3c.github.io/typography/

r12a: The question is if specdev should have explanatory text, or just be an index.

<r12a> 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> 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> 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> 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> https://lists.w3.org/Archives/Member/w3c-css-wg/2020OctDec/0042.html

Note that they use Google Meet. May work best with Chrome.

- DRAFT -

Internationalization Working Group Teleconference

22 Oct 2020

Attendees

Contents