[minutes] Internationalization telecon 2020-10-22


text extract follows:


            Internationalization Working Group Teleconference

22 Oct 2020


       [2] https://www.w3.org/wiki/I18N_2020_TPAC


           Addison, Vainateya, Richard, Atsushi, Bert, xfq

           Felix, JcK

           Addison Phillips



      * [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

    <scribe> scribe: Bert


    <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

Action Items


      [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


      [16] https://www.w3.org/International/track/actions/895

    addison: Do I need to summarize?
    ... font fingerprinting, we talked about it with CSS on


      [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
    ... 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

    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


      [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


      [20] https://www.w3.org/International/track/actions/964

    <addison> close action-964

    <trackbot> Closed action-964.


      [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


      [22] https://www.w3.org/International/track/actions/968

    <addison> close action-968

    <trackbot> Closed action-968.


    <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


      [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

    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


      [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


      [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
    ... Please read my text and react.

    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

    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

    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.


      [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

    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

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.


      [38] https://w3c.github.io/bp-i18n-specdev/#sec_lang_values

    r12a: E.g., look at 2.2
    ... 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

    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

    r12a: Is that a goal, or just happens to be?

    addison: So specdev would be just a checklist and all prose is

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


      [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

    r12a: We recommend people to use the checklist ^^ rather than
    ... 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
    ... 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.


      [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.


      [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

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

    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

    <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

    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

    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.


    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

    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
    ... But you often cannot easily find the text.

    addison: There are things I cannot help with. Should spread
    ... Good if r12a sets things up, but we should get it to a
    point that others can contribute.


    <addison> CSS: 7:30 Pacific (1430UTC)


      [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