- From: Fuqiao Xue <xfq@w3.org>
- Date: Fri, 7 Mar 2025 10:23:47 +0800
- To: www-international@w3.org
https://www.w3.org/2025/03/06-i18n-minutes.html text version: – DRAFT – Internationalization Working Group Teleconference 06 March 2025 [2]Agenda. [3]IRC log. [2] https://www.w3.org/events/meetings/b7edae68-f52c-4aab-a1a6-3c37459e0786/20250306T150000/ [3] https://www.w3.org/2025/03/06-i18n-irc Attendees Present Addison, Bert, Fuqiao, JcK, Nat, Richard Regrets - Chair Addison Phillips Scribe xfq Contents 1. [4]Agenda Review 2. [5]Action Items 3. [6]Info Share 4. [7]Review RADAR 5. [8]Pending Issue Review 6. [9]Specdev and "Typographic Unit" PR 7. [10]How to make list markers stand upright in vertical text 8. [11]I18N Glossary Options 9. [12]local fonts vs privacy: activity#1988 (css#11648) 10. [13]AOB? Meeting minutes <gb> Issue 11648 not found <gb> Issue 1988 not found <gb> Issue 1988 not found <gb> Issue 11648 not found Agenda Review Action Items <addison> [14]https://github.com/w3c/i18n-actions/issues [14] https://github.com/w3c/i18n-actions/issues <addison> #160 <gb> [15]Action 160 review graphemes in specdev and add balinese example and otherwise fix the text (on aphillips) due 2025-03-06 [15] https://github.com/w3c/i18n-actions/issues/160 <addison> #159 <gb> [16]Action 159 write up proposal for specdev char-string section, adding material that deals with the encoding interface et al (on aphillips) due 2025-02-27 [16] https://github.com/w3c/i18n-actions/issues/159 addison: #159 is related to another agenda item <addison> #157 <gb> [17]Action 157 write glossary proposal identifying options and next steps for those options (on aphillips) due 2025-02-20 [17] https://github.com/w3c/i18n-actions/issues/157 addison: #157 is on the agenda today <addison> #135 <gb> [18]Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17 [18] https://github.com/w3c/i18n-actions/issues/135 <addison> #127 <gb> [19]Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30 [19] https://github.com/w3c/i18n-actions/issues/127 <addison> #89 <gb> [20]Action 89 update i18n specs to support dark mode (on xfq) due 2024-04-18 [20] https://github.com/w3c/i18n-actions/issues/89 addison: #135, starting trading some Slack conversation with Manish, still pending <addison> #33 <gb> [21]Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips) [21] https://github.com/w3c/i18n-actions/issues/33 <addison> #7 <gb> [22]Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023 [22] https://github.com/w3c/i18n-actions/issues/7 <addison> #4 <gb> [23]Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023 [23] https://github.com/w3c/i18n-actions/issues/4 Info Share addison: in a very short period of time the USA will switch to DST <addison> [24]https://lists.w3.org/Archives/Public/ public-i18n-core/2025JanMar/0055.html [24] https://lists.w3.org/Archives/Public/public-i18n-core/2025JanMar/0055.html <addison> [25]https://w3c.github.io/i18n-drafts/articles/ definitions-characters/index.en.html [25] https://w3c.github.io/i18n-drafts/articles/definitions-characters/index.en.html r12a: did everybody read it and think it was okay? <addison> (note to self: steal richard's version of the family emoji for specdev) <r12a> [26]https://w3c.github.io/i18n-drafts/articles/ definitions-characters/index.en.html#characters [26] https://w3c.github.io/i18n-drafts/articles/definitions-characters/index.en.html#characters r12a: here's the direct link … what I changed ^ [Discuss emoji issues in specdev] <addison> [27]https:// deploy-preview-153--bp-i18n-specdev.netlify.app/#characters [27] https://deploy-preview-153--bp-i18n-specdev.netlify.app/#characters <addison> [28]https:// deploy-preview-153--bp-i18n-specdev.netlify.app/#family-example [28] https://deploy-preview-153--bp-i18n-specdev.netlify.app/#family-example [29]https://emojipedia.org/family#designs [29] https://emojipedia.org/family#designs Review RADAR <addison> [30]https://github.com/orgs/w3c/projects/91/views/1 [30] https://github.com/orgs/w3c/projects/91/views/1 Pending Issue Review <addison> [31]https://github.com/w3c/i18n-activity/ issues?q=is%3Aissue+is%3Aopen+label%3Apending [31] https://github.com/w3c/i18n-activity/issues?q=is:issue+is:open+label:pending <gb> Issue 1988 not found <gb> Issue 11648 not found Specdev and "Typographic Unit" PR addison: pending issues, nothing super exciting here, except the one with agenda+ … which I've added to the agenda <addison> [32]w3c/bp-i18n-specdev#153 [32] https://github.com/w3c/bp-i18n-specdev/pull/153 <gb> [33]Pull Request 153 Replace Bangla example, replace user-perceived character (by aphillips) [33] https://github.com/w3c/bp-i18n-specdev/pull/153 <addison> [34]https:// deploy-preview-153--bp-i18n-specdev.netlify.app/#characters [34] https://deploy-preview-153--bp-i18n-specdev.netlify.app/#characters addison: there are two primary changes … we'll start with the first one, which is characters … the goal here was to replace our use of grapheme and glyph and such with the term typographical unit <addison> Specifications SHOULD use the term code point instead of the term 'character'. If the term 'character' is used, it MUST be explicitly defined to mean a Unicode code point. The term Unicode Scalar Value MAY also be used. addison: or the term user perceived character with typographical unit <addison> (the old: Specifications SHOULD explicitly define the term 'character' to mean a Unicode code point.) nmccully: I'm wondering, did anyone raise concern that typographical unit is often used for measurement and not linguistic character xfq: yes, people in clreq TF also raised this concern before <addison> Specifications SHOULD explicitly define the term 'character' to mean a Unicode code point. nmccully: I find it to be more opaque than grapheme cluster or linguistic character unit <addison> [35]https://www.w3.org/TR/ i18n-glossary/#dfn-typographic-character-unit [35] https://www.w3.org/TR/i18n-glossary/#dfn-typographic-character-unit nmccully: typographic unit to me is a upm or a point or something like that addison: that's fair r12a: but we do mean something that is kind of vague and not clearly defined and may change in different places … similar to the CSS definition … the this is viewed from the user's point of view rather than from a machine point of view nmccully: yeah, that's a good point addison: you're trying to say grapheme cluster but not exactly Unicode's grapheme cluster because that turns out to be problematic sometimes r12a: we're trying to get away from the implementation … this could be just writing on a piece of paper nmccully: ok, so character unit r12a: yeah, but then it sounds like a single code point <addison> [36]https:// deploy-preview-153--bp-i18n-specdev.netlify.app/#characters [36] https://deploy-preview-153--bp-i18n-specdev.netlify.app/#characters addison: if you look at example 7, we go back to the Hindi thing and we show the syllables as well as the syllables typographical units with one of them highlighted and we show that that's broken into underlying characters nmccully: I think I would call that a typographic character … it's unit in the other sense of the term r12a: which is probably the most widespread use of the term nmccully: for British people nmccully: what's wrong with 'character'? nmccully: I've tried not to say a 'Unicode character' because character can to some people mean accented E or whatever and it's more than one Unicode code point nmccully: the other thing that bothers me is you're talking about typographic when you want to refer to writing too <addison> 'visual unit' addison: visible text unit? [37]https://www.w3.org/TR/typography/#typographic_units [37] https://www.w3.org/TR/typography/#typographic_units addison: we don't expect people to use this term, whatever term we choose <addison> [38]https:// deploy-preview-153--bp-i18n-specdev.netlify.app/#char_truncatio n [38] https://deploy-preview-153--bp-i18n-specdev.netlify.app/#char_truncation xfq: our LE index already uses this term as its section name addison: should we try visible text units? nat: it's a bit better for me addison: all right, I will make that change and try this again … let me point out the other section that got changed here … in 6.5 Truncating or limiting the length of strings r12a: I think the example could be better if you went one byte further … in the English I would say "I can eat glass," addison: this needs more work … good suggestions … maybe I'll unbox the example and just have it be plain text <addison> In an earlier example (Example 9), the composed "family" emoji sequence "👨👩👧👧" consists of 7 code points. The byte limit of 15 truncates after the second family member: "👨👩". <gb> Issue 11648 not found <gb> Issue 1988 not found How to make list markers stand upright in vertical text <r12a> [39]https://w3c.github.io/i18n-drafts/questions/ qa-upright-counters-in-vertical.html#additional_styling [39] https://w3c.github.io/i18n-drafts/questions/qa-upright-counters-in-vertical.html#additional_styling r12a: this is about the whole article, but I've zoomed in on a particular place ^ … where I've just made some changes … I had only one outstanding issue after sending this out for review … it was to do with the properties that you can apply … the CSS styles that you can apply to the ::marker pseudo element … originally I had just said CSS allows you to apply these properties and that was it … Blink allows you to do more properties than that … and some of these properties are not supported in Safari <addison> interactive test: [40]https://w3c.github.io/ i18n-tests/exploratory/ index.html?text=%3Col%3E%0A%3Cli%20id%3D%22color%22%3Ecolor%3C% 2Fli%3E%0A%3Cli%20id%3D%22content%22%3Econtent%3C%2Fli%3E%0A%3C li%20id%3D%22fontstyle%22%3Efont-style%3C%2Fli%3E%0A%3Cli%20id% 3D%22fontvariant%22%3Efont-variant%3C%2Fli%3E%0A%3Cli%20id%3D%2 2fontweight%22%3Efont-weight%3C%2Fl [40] https://w3c.github.io/i18n-tests/exploratory/index.html?text=<ol> <addison> i%3E%0A%3Cli%20id%3D%22fontfamily%22%3Efont-family%3C%2Fli%3E%0 A%3Cli%20id%3D%22direction%22%3Edirection%3C%2Fli%3E%0A%3Cli%20 id%3D%22textshadow%22%3Etext-shadow%3C%2Fli%3E%0A%3Cli%20id%3D% 22texttransform%22%3Etext-transform%3C%2Fli%3E%0A%3C%2Fol%3E&cs s=.test%20li%20%7B%20list-style-type%3A%20lower-alpha%3B%20marg in-inline-start%3A%203rem%3B%20%7D% <addison> 0A%23color%3A%3Amarker%20%7B%20color%3A%20lightgreen%3B%20%7D%0 A%23content%3A%3Amarker%20%7B%20content%3A%20%27%40.%20%27%3B%2 0%7D%0A%23fontstyle%3A%3Amarker%20%7B%20font-style%3A%20italic% 3B%20%7D%0A%23fontvariant%3A%3Amarker%20%7B%20font-variant%3A%2 0small-caps%3B%20%7D%0A%23fontweight%3A%3Amarker%20%7B%20font-w eight%3A%20bold%3B%20%7D%0A%23fontf <addison> amily%3A%3Amarker%20%7B%20font-family%3A%20Consolas%2C%20%27And ale%20Mono%27%2C%20%27Lucida%20Console%27%2C%20%27Lucida%20Sans %20Typewriter%27%2C%20Monaco%2C%20%27Courier%20New%27%2C%20%27m onospace%27%3B%20%7D%0A%23direction%3A%3Amarker%20%7B%20directi on%3A%20rtl%3B%20%7D%0A%23textshadow%3A%3Amarker%20%7B%20text-s hadow%3A%200%200%205px%3B%20%7D%0A% <addison> 23texttransform%3A%3Amarker%20%7B%20text-transform%3A%20upperca se%3B%20%7D%0A&fontSize=36&width=500&height=500&a=Various%20sty les%20indicated%20in%20the%20CSS%20spec%20are%20supported%20for %20%3A%3Amarker.&i=Test%20passes%20if%20you%20see%20the%20expec ted%20styling%20for%20each%20line. r12a: there's a link that goes to a test that I put together this morning which you might find of interest if you click on that link … that's the latest edition … otherwise I'm hoping that this article is now stable enough … to publish nmccully: the only objections I would raise are to encourage the particular choice of numbering you've done for vertical is IMO not the mainstream … I think jlreq plans to talk about this in terms of what is more traditional <gb> Issue 11648 not found <gb> Issue 1988 not found r12a: good suggestion, I can add that addison: anybody object to our publishing this? … right, thank you, r12a, for all your work on this … this is really good stuff as usual <r12a> [41]https://w3c.github.io/i18n-drafts/questions/ qa-the-q-element.en.html [41] https://w3c.github.io/i18n-drafts/questions/qa-the-q-element.en.html r12a: just so you're aware, there's another one on the boil that might take as long as well … which is about the q element … I haven't uploaded the latest version … fantasai and florian had a long conversation about that and came up with "well, this is what the CSS ought to look like" … but it's sort of future … it's not even in the spec yet … with the match-parent and stuff like that and auto values … so I have to figure out what you can do in the meantime to make this work … and I'm not quite sure how to do it … but I wanted to let you know that I'm working on that … I should update the draft nmccully: Korean @@ French not using thin space etc. r12a: I should redo that example I18N Glossary Options <addison> [42]https://docs.google.com/document/d/ 1jGup6Z9dO0OAeSfM6zZhTeT_E5eM9lDOVWo_Ec37mn0/edit [42] https://docs.google.com/document/d/1jGup6Z9dO0OAeSfM6zZhTeT_E5eM9lDOVWo_Ec37mn0/edit addison: I had an action to look at different ways we've been discussing what to do with the i18n glossary … and pulling together some different options … four things I could think of based on our previous conversation for what to do with the glossary … see ^ … the history is we have this glossary document, and we tell people to link to terms in it when they need it … like you need to say 'locale' and your spec has nothing to do with locales but you need to link to a def … link to ours, it's exported … it's easy to get … it works automatically in respec and bikeshed … but those tools produce a warning when you do that in a normative block because our glossary is a note … but we would like to provide people a way to use our jargon 'code point' … effectively without having to copy the def into every single spec <addison> #155 <gb> [43]CLOSED Action 155 review glossary definitions for normativity or candidates for normativity (on aphillips) due 2025-01-23 [43] https://github.com/w3c/i18n-actions/issues/155 addison: and when we change the def, go hunt all those people down and fix it r12a: I think part of the homework here was actually to derive a list of which of these things needed to be normative addison: one of the things that's interesting is the Unicode glossary has no normativity xfq: because the Unicode Core Spec defines a lot of the terms addison: it used to be the TUS was not something you could access from the web, and now that it is … one potential option E would be specdev does a lot of this work xfq: specdev is also a note addison: yeah, but it's also the best practices document and we have mustard in it … it also straddles the line … maybe it doesn't fix this entirely … but it solves a couple of problems, one of them being that we would like to deprecate charmod fundamentals <gb> Issue 1988 not found <gb> Issue 11648 not found local fonts vs privacy: [44]activity#1988 ([45]css#11648) [44] https://github.com/w3c/activity/issues/1988 [45] https://github.com/w3c/css/issues/11648 <addison> [46]i18n-activity#1988 [46] https://github.com/w3c/i18n-activity/issues/1988 <gb> [47]Issue 1988 [css-fonts-4] Detection-prevention approach to the local font privacy issue (by w3cbot) [pending] [tracker] [s:css-fonts] [wg:css] [Agenda+] [47] https://github.com/w3c/i18n-activity/issues/1988 <addison> [48]w3c/csswg-drafts#11648 [48] https://github.com/w3c/csswg-drafts/issues/11648 <gb> [49]Issue 11648 [css-fonts] Detection-prevention approach to the local font privacy issue (by noamr) [css-fonts-4] [i18n-tracker] [privacy-tracker] [49] https://github.com/w3c/csswg-drafts/issues/11648 xfq: we should link to this doc somewhere in github addison: I wanted to bring this up ^ … new proposal for the local font privacy issue r12a: it's now like you're reading a book to get your head around this issue … Chris put a list of links to issues on this topic … he had an explainer that we were using … in the TPAC discussion AOB? nmccully: we're really at a crossroads where Unicode being inadequate for typography and depending on fonts and fonts having such chaos in terms of how they support each language … for our use case and our apps are suffering greatly by not having access to the fonts in the system
Received on Friday, 7 March 2025 02:24:01 UTC