IRC log of i18n on 2024-09-23

Timestamps are in UTC.

14:59:01 [RRSAgent]: RRSAgent has joined #i18n
14:59:05 [RRSAgent]: logging to https://www.w3.org/2024/09/23-i18n-irc
14:59:18 [addison]: Meeting: Internationalization TPAC 2024
14:59:22 [addison]: Chair: Addison Phillips
14:59:30 [agendabot]: agenda: https://www.w3.org/events/meetings/900ac419-eda7-404d-9750-d87b8c83dc05/
14:59:30 [agendabot]: clear agenda
14:59:30 [agendabot]: agenda+ Agenda Review
14:59:30 [agendabot]: agenda+ Planning for this week
14:59:32 [agendabot]: agenda+ Document Work in Progress Review
14:59:34 [agendabot]: agenda+ Language Enablement WIP
14:59:35 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
14:59:37 [agendabot]: agenda+ AOB?
15:38:36 [addison]: addison has joined #i18n
15:39:16 [addison]: present+ Addison, Florian
16:00:49 [addison]: addison has joined #i18n
16:00:52 [bigbluehat]: bigbluehat has joined #i18n
16:01:52 [addison]: addison has joined #i18n
16:03:12 [addison]: addison has joined #i18n
16:04:15 [addison]: addison has joined #i18n
16:05:20 [addison]: addison has joined #i18n
16:06:41 [addison]: addison has joined #i18n
16:07:52 [addison]: addison has joined #i18n
16:09:30 [addison]: addison has joined #i18n
16:10:43 [addison]: addison has joined #i18n
16:11:01 [addison]: agenda?
16:11:08 [addison]: zakim, take up agendum 1
16:11:09 [Zakim]: agendum 1 -- Agenda Review -- taken up [from agendabot]
16:13:37 [addison]: agenda+ review issues
16:14:21 [addison]: #123
16:14:23 [gb]: https://github.com/w3c/i18n-actions/issues/123 -> Action 123 reach out to the privacy person (Tara?) about meeting at TPAC (on xfq) due 2024-09-26
16:14:32 [atsushi]: atsushi has joined #i18n
16:14:40 [addison]: no reply yet
16:15:11 [addison]: zakim, take up agendum 2
16:15:11 [Zakim]: agendum 2 -- Planning for this week -- taken up [from agendabot]
16:25:16 [addison]: https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+label%3AAgenda%2BI18N%2BWHATWG
16:34:09 [xfq]: https://github.com/w3c/i18n-activity/issues?q=is%3Aopen+is%3Aissue+label%3As%3Ainfra
16:38:48 [addison]: https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+label%3AAgenda%2BI18N%2BCSS
16:42:25 [addison]: https://lists.w3.org/Archives/Public/public-i18n-core/2024AprJun/0069.html
16:53:35 [addison]: action: addison: propose creating a UTR for text-emphasis skip if we can get help with maintain
16:53:43 [gb]: Created -> action #125 https://github.com/w3c/i18n-actions/issues/125
16:54:22 [addison]: https://github.com/w3c/csswg-drafts/issues/4154
16:54:23 [gb]: https://github.com/w3c/csswg-drafts/issues/4154 -> Issue 4154 Consider Canonicalization of language tags in :lang() selector maching (by frivoal) [selectors-4] [i18n-tracker] [Needs Review of Proposed Text] [selectors-5] [Agenda+ i18n]
17:01:50 [xfq]: rrsagent, make minutes
17:01:51 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
17:02:08 [xfq]: present+
17:09:24 [xfq]: https://zh-yue.wikipedia.org/wiki/%E7%B6%AD%E5%9F%BA%E7%99%BE%E7%A7%91
17:09:26 [xfq]: wikipedia uses lang="yue"
17:12:30 [xfq]: [Discuss whether :lang(zh-*) should match lang="yue"]
17:18:51 [addison]: css selectors :lang match if their subtags match or if, after canonicalization, they match
17:19:42 [addison]: RESOLVED: (our intention is) css selectors :lang match if their subtags match or if, after canonicalization, they match
17:23:04 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
17:33:24 [r12a]: r12a has joined #i18n
17:51:22 [r12a]: i think Uzbekistan is currently in the process of changing from Cyrillic to Latin
17:51:51 [r12a]: you may also find this app useful for some parts of this discussion https://r12a.github.io/app-subtags/index.html
17:52:14 [r12a]: https://r12a.github.io/app-subtags/?find=zh
18:08:40 [xfq]: scribe+
18:09:03 [addison]: #1909
18:09:04 [gb]: Issue 1909 not found
18:09:20 [addison]: https://github.com/w3c/i18n-activity/issues/1909
18:09:21 [gb]: https://github.com/w3c/i18n-activity/issues/1909 -> Issue 1909 Should ACT require the formats for rules to be localizable? (by bert-github) [pending] [s:act-rules-format]
18:09:54 [xfq]: Bert: I found some editorial issues as well, but I"ll post to them directly
18:10:29 [xfq]: ... ACT doesn't describe the specific format for rules
18:10:30 [addison]: https://www.w3.org/TR/2024/WD-act-rules-format-1.1-20240618/#rule-description
18:10:36 [xfq]: ... it says you can use PDF or HTML
18:11:05 [xfq]: ... they don't require that the human description is in a recognizable language
18:11:10 [xfq]: ... it has to be plain language
18:11:40 [xfq]: ... do we need to say that the format needs to be capable of labeling that language?
18:11:51 [xfq]: ... unless that's implicit in being accessible
18:12:14 [xfq]: ... assuming it's HTML, you can label
18:12:35 [xfq]: ... but if it's another format, I don't know
18:13:03 [xfq]: xfq: what does they use the ACT rule for?
18:13:17 [xfq]: Bert: it's a format for storing accessibility checks
18:13:31 [xfq]: ... it's not machine readble
18:13:37 [xfq]: ... it's human readable
18:14:27 [xfq]: addison: you could build a machine readable thing around all of this
18:14:35 [xfq]: ... but they don't require it
18:15:27 [xfq]: ... @@
18:15:46 [xfq]: Bert: the format should not only be accessible but also be localizable
18:16:09 [xfq]: addison: by itself it's not wrong or right
18:17:00 [xfq]: addison: I think it would be good to say that they should have some text about providing localization
18:17:07 [xfq]: ... even if it's not normative
18:17:10 [xfq]: Bert: OK
18:17:16 [addison]: #1910
18:17:16 [gb]: Issue 1910 not found
18:17:24 [addison]: gb, help
18:17:24 [gb]: addison, I am a bot to look up and create GitHub issues and
18:17:24 [gb]: … action items. I am an instance of GHURLBot 0.5.
18:17:24 [gb]: … Try gb, help commands or
18:17:24 [gb]: … see https://w3c.github.io/GHURLBot/manual.html
18:17:35 [addison]: gb, repo
18:17:36 [gb]: addison, sorry, I don't understand what you want me to do. Maybe try "help"?
18:17:55 [addison]: gb, use
18:17:55 [gb]: addison, sorry, I don't understand what you want me to do. Maybe try "help"?
18:17:57 [xfq]: https://github.com/w3c/i18n-activity/issues/1910
18:17:58 [gb]: https://github.com/w3c/i18n-activity/issues/1910 -> Issue 1910 How are rule identifiers matched to one another? (by bert-github) [pending] [s:act-rules-format]
18:18:02 [xfq]: Bert: they have a rule Identifier
18:18:13 [xfq]: ... they says this identifier must be unique
18:18:26 [xfq]: ... but it is not specified how identifiers are compared
18:18:41 [xfq]: ... or if they are normalized
18:18:55 [xfq]: ... any recommendation?
18:19:25 [xfq]: addison: how does it enforce?
18:19:32 [xfq]: ... charmod-norm
18:20:04 [addison]: https://github.com/w3c/i18n-activity/issues/1911
18:20:04 [xfq]: present+ fantasai
18:20:04 [gb]: https://github.com/w3c/i18n-activity/issues/1911 -> Issue 1911 ACT does not require that the language of text is indicated (by bert-github) [pending] [s:act-rules-format]
18:20:49 [xfq]: Bert: It does not say anything about which human language
18:21:01 [atsushi_web]: atsushi_web has joined #i18n
18:22:09 [r12a]: present+ r12a
18:22:23 [xfq]: xfq: does "plain language" mean easily understandable language, or does it mean natural language?
18:23:42 [xfq]: Bert: I think it means easily understandable language
18:24:16 [addison]: https://github.com/w3c/i18n-activity/issues/1912
18:24:17 [gb]: https://github.com/w3c/i18n-activity/issues/1912 -> Issue 1912 Is the ‘descriptive title’ used for matching? (by bert-github) [pending] [s:act-rules-format]
18:24:41 [xfq]: Bert: composite rule
18:25:21 [xfq]: ... it refers to atomic rules with descriptive titles
18:25:49 [xfq]: ... I don't know if the descriptive title is used for matching or searching
18:26:13 [xfq]: addison: in the EU they're gonna require at least 2 languages
18:29:24 [gb]: https://github.com/w3c/transitions/issues/129 -> CLOSED Issue 129 [AGWG] CR transition for ACT-Rules-Format (by nitedog) [Entering CR] [wg:ag]
18:30:43 [addison]: action: addison: check if ACT 1.0 was reviewed
18:30:44 [gb]: Created -> action #126 https://github.com/w3c/i18n-actions/issues/126
18:33:07 [addison]: https://github.com/w3c/string-meta
18:33:31 [xfq]: addison: reasonably soon, I'd like to consider transitioning string-meta to Note
18:33:51 [xfq]: ... not just because I'm gonna go to the UTW workshop next month and talk about it
18:33:59 [xfq]: ... we've done mostly the work on this
18:34:13 [xfq]: ... we could look at buttoning up this spec being finished
18:35:55 [xfq]: https://www.w3.org/policies/process/#note-track
18:36:50 [xfq]: xfq: @@ see the process ^
18:37:05 [xfq]: addison: I think that would be good to have
18:37:12 [xfq]: ... to say that this is our current thinking
18:37:18 [xfq]: ... do others disagree?
18:38:05 [xfq]: [silence]
18:38:06 [xfq]: addison: I think most of our changes are in
18:38:17 [xfq]: ... we have producers and consumers stuff
18:39:02 [xfq]: xfq: we have 15 open issues
18:39:04 [xfq]: https://github.com/w3c/string-meta/issues
18:39:30 [addison]: https://github.com/w3c/timezone
18:39:54 [xfq]: addison: I've been working on an update to Working with time and time zones
18:40:03 [addison]: https://w3c.github.io/timezone/
18:40:03 [xfq]: ... formerly called Working with time zones
18:40:14 [xfq]: ... I'd like to get this enough shape to publish the new one
18:40:28 [xfq]: ... because I think it has a bunch of valuable information
18:40:48 [xfq]: eemeli: I have looked at it
18:41:17 [xfq]: ... when reading it I did not get a sense of who is supposed to do what with this
18:41:33 [xfq]: addison: it's mostly directed at developers
18:41:41 [xfq]: ... who need to work with time and time zones
18:41:50 [xfq]: ... input type=time
18:41:58 [xfq]: ... when do we get serialization
18:42:21 [xfq]: ... mostly this is about if I'm writing a web page I should do X, I should not do X
18:42:56 [xfq]: present+ Aki
18:43:41 [aki]: aki has joined #i18n
18:43:53 [xfq]: rrsagent, make minutes
18:43:54 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
18:44:41 [xfq]: addison: the sedate things are from RFC 9557
18:44:54 [xfq]: eemeli: proposed standard from April this year
18:45:28 [xfq]: addison: I would welcome comments
18:45:33 [addison]: https://github.com/w3c/string-search
18:45:54 [addison]: https://github.com/w3c/string-search
18:46:06 [xfq]: addison: string-search
18:46:14 [xfq]: ... we have an open PR
18:46:21 [addison]: https://deploy-preview-23--w3c-string-search.netlify.app/
18:46:21 [xfq]: ... stealing text from Henry
18:46:45 [xfq]: ... we took all of the string search and find stuff out of charmod-norm
18:46:52 [xfq]: ... that we could finish in our lifetime
18:47:09 [xfq]: ... since then there have been at least 3 efforts to write down how find works
18:47:12 [xfq]: ... in the browser
18:47:41 [xfq]: ... including one that's currently incubating somewhere
18:47:54 [addison]: https://deploy-preview-23--w3c-string-search.netlify.app/#text-frag-lang
18:48:19 [xfq]: ... in the bullet list ^
18:48:39 [xfq]: ... if you search for each one of those words you can see what you would expect to find
18:48:53 [xfq]: ... assuming that the string is tagged with the language properly
18:49:06 [xfq]: ... obvious you can see what the browsers currently do
18:49:20 [xfq]: ... the question is whether those are the things that they should do
18:50:02 [xfq]: ... there was an attempt to make it use the collator
18:50:56 [xfq]: ... you could type han, you could be lazy on inputting
18:51:13 [xfq]: ... there's a feature for ignoring case
18:52:08 [xfq]: xfq: not just the UI, also the window.find() method
18:52:29 [xfq]: eemeli: any performance constraints?
18:53:05 [xfq]: addison: I'd like to finish the beta of this thing
18:53:17 [xfq]: ... because we keep coming back to it every 3 or 4 years
18:53:27 [xfq]: ... when somebody discovers that they want to write find
18:54:32 [xfq]: addison: Shane Carr reached out to me
18:55:27 [xfq]: Aki: Hi, I'm Aki Braun, former chair of TC 39
18:55:49 [xfq]: ... I'm here on behalf of Ecma International Secretary
18:56:13 [xfq]: ... I'm trying to figure out ways that our SDOs could be working together
18:56:52 [xfq]: addison: there's a steady stream of of API and additions and complications
18:57:06 [xfq]: ... we want to develop in some sort of orderly fashion
18:57:22 [xfq]: ... my other hat is the Unicode chair of MessageFormat
18:57:41 [xfq]: ... it is ended up being effectively a templating language for strings
18:57:54 [xfq]: ... what it really wants to have is a resource container
18:58:12 [xfq]: ... the status of ES 10 years ago was not internationalized
18:58:21 [xfq]: ... we're playing catch up
18:58:33 [xfq]: ... in increasingly ordered and structred way
18:59:49 [xfq]: eemeli: my take is JS has a need for having the ability in order to be able to do message as a whole in a decent way
19:00:14 [xfq]: ... it probably makes more sense from a message resource @@ defined somewhere other than TC 39
19:00:25 [xfq]: ... I'll be at the UTW and have a session
19:00:48 [xfq]: ... @@
19:00:57 [xfq]: Aki: TC 57
19:01:08 [xfq]: eemeli: I presume that's the next available number, yes
19:01:24 [xfq]: ... the resource format is currently in this sort of uncomfortable space
19:01:32 [xfq]: ... where we've done a small bunch of work
19:01:48 [xfq]: ... but we don't know where technically this work
19:02:24 [xfq]: addison: I can tell you the number specs where people are revinting packaging
19:02:33 [xfq]: ... 9 ways of doing this
19:03:31 [xfq]: ... we can find one place to hold the best practices
19:04:12 [xfq]: Aki: we need to figure out that stuff not just for the web but broader than the web
19:04:36 [xfq]: ... we as a group of SDOs like Unicode and W3C are sort of keeping an eye on what each other is up to
19:05:16 [xfq]: addison: how is the locale model implemented in HTML and looks like for JS
19:05:50 [xfq]: Aki: @@
19:06:06 [xfq]: addison: classical timekeeping, milliseconds since the epoch
19:06:40 [xfq]: ... Temporal promises to solve that, but it exposes a bunch of these concepts which I'm not even sure if groups understand it
19:07:22 [xfq]: ... I'm a little frustrated because it's a lot easier to work with people to teacher developers to use Temporal
19:09:11 [xfq]: addison: this group don't review all RFCs or Unicode work but we occasionally glance them
19:09:36 [xfq]: ... we host some amount of article like material for explaining things and we use MDN
19:10:12 [xfq]: [Aki shows a document that says Ecma-liaison agreement on it]
19:10:22 [xfq]: s/Ecma-/Ecma-W3C/
19:11:08 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
19:11:50 [xfq]: eemeli: it's challenging to keep on participating in because this WG deals a lot of content that is not directly relevant to TC 39 JS work
19:12:09 [r12a]: q+
19:12:34 [addison]: ack next
19:12:39 [xfq]: Aki: @@
19:12:42 [xfq]: ... when this come up we're gonna reach out to each other or schedule a joint meeting
19:13:02 [xfq]: r12a: I was actually gonna suggest something very similar
19:13:21 [xfq]: ... could be that we put a @@ list together
19:13:37 [xfq]: ... things that we think we're working on, string-meta, for example
19:13:44 [xfq]: ... time and time zones
19:13:54 [xfq]: ... the other folks would be interested in
19:14:01 [xfq]: ... and collaborating on
19:14:12 [xfq]: ... if we had a page somewhere
19:14:13 [r12a]: s/@@/reading/
19:14:33 [xfq]: ... and then we could point to the documents where people could see what we're doing
19:14:49 [xfq]: rrsagent, make minutes
19:14:50 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
19:15:12 [xfq]: present+ Bert
19:15:36 [xfq]: addison: any actions we can take?
19:15:58 [xfq]: Aki: in the next few months, if you could come up with some areas where you think it would be relevant
19:16:09 [xfq]: ... it would be helpful to talk to each other
19:16:15 [addison]: action: addison: make a list of shared topics of interest between TG2 and W3C-I18N
19:16:16 [gb]: Created -> action #127 https://github.com/w3c/i18n-actions/issues/127
19:16:44 [xfq]: ... that could help me figure out things like how we could formalize relationships so that we could just have a joint meeting
19:17:24 [xfq]: addison: r12a is working on language enablement
19:18:58 [xfq]: xfq: @@
19:19:26 [xfq]: ... like custom dictionary for text segmentation (like Intl.Segmenter)
19:20:26 [aki]: shoot me an email at hi@akiro.se with any intersecting topic ideas
19:20:43 [xfq]: r12a: if you're doing segmentation stuff we have problems that arise when you're doing this on a worldwide basis rather than just for English
19:20:47 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
19:21:39 [r12a]: https://www.w3.org/TR/jpan-lreq/#segmentation
19:23:15 [xfq]: eemeli: we're not quite ready to have a full proposal, but we have been discussing to have a locale that would communicate to users that they want "Standard English"
19:23:34 [xfq]: ... but without all the specific i18n aspects of American English attached
19:23:57 [xfq]: ... what we've been kind of considering is specifically using a region code ZZ
19:23:59 [xfq]: ... en-ZZ
19:24:21 [xfq]: r12a: wouldn't that just be en?
19:24:41 [xfq]: eemeli: the problem is that the web reality is that en translate to en-US currently
19:24:54 [xfq]: ... and changing that to something else would break way too many things
19:25:07 [xfq]: Bert: in what way does it map to American English?
19:25:29 [xfq]: eemeli: week numbering is American rather than the ISO way of doing it
19:25:40 [xfq]: ... weeks start on Sundays rather than Mondays
19:25:59 [xfq]: Aki: is this for historical reasons?
19:26:20 [xfq]: eemeli: this is a real world problem
19:26:40 [xfq]: ... very clear majority of en-US localization of Firefox users are coming from outside the USA
19:26:53 [xfq]: ... because that is the default effectively
19:27:11 [xfq]: ... they chose English but what they end up getting is English with American
19:28:08 [xfq]: r12a: why leave the spelling in American spelling? because again my understanding is that most of the world uses British spelling for colour
19:28:27 [xfq]: addison: I think that's only partially true
19:28:42 [r12a]: how about en-001
19:29:35 [xfq]: ... what we call euphemistically international English which is British spellings, many parts of the world which have adopted US spelling as preferred, UAE as an example
19:31:08 [xfq]: addison: @@
19:31:20 [xfq]: ... CLDR adding every country code under English
19:31:22 [xfq]: ... en-AQ
19:32:18 [xfq]: eemeli: if we use en-ZZ the sensible thing that would be to go with year-month-day
19:32:34 [xfq]: addison: the starting point would be the CLDR-TC
19:32:50 [xfq]: ... whatever happens they have to manage the data for you
19:33:15 [xfq]: ... es-419, nobody lives in 419
19:34:07 [xfq]: eemeli: you need to make Americans still get the American experience
19:34:32 [xfq]: addison: what do we call it? we already have International English
19:37:16 [xfq]: addison: en-IE, en-DE etc. differ only in a very small set of tailorable of the data
19:37:32 [xfq]: ... usually not the dominant language of the country
19:38:59 [xfq]: ... I don't know the solution, but @@ fallback
19:40:20 [xfq]: eemeli: 001 does not work because it's got an established practice
19:40:28 [xfq]: ... it's already used by CLDR
19:40:36 [xfq]: ... don't always work in all places
19:42:25 [xfq]: rrsagent, make minutes
19:42:26 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
19:44:13 [addison]: addison has joined #i18n
19:44:17 [addison]: https://www.w3.org/groups/wg/i18n-core/calendar/
19:47:02 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
20:47:43 [addison]: addison has joined #i18n
20:55:17 [gb]: https://github.com/w3c/webextensions/pull/569 -> Pull Request 569 Proposal: i18n-system-languages (by carlosjeurissen) [topic: localization] [i18n-tracker]
20:55:56 [addison]: gb, status
20:55:56 [gb]: addison, the delay is 15, issues are on, names are off, full issues are printed 10 at a time; and the repository is https://github.com/w3c/i18n-actions
21:02:06 [Bert]: scribe+
21:02:21 [jyasskin]: jyasskin has joined #i18n
21:03:43 [atsushi]: atsushi has joined #i18n
21:04:05 [addison]: agenda+ date/time pr
21:04:07 [addison]: agenda?
21:04:31 [addison]: https://github.com/w3c/bp-i18n-specdev/
21:04:53 [Bert]: addison: Let's start with specdev.
21:05:14 [Bert]: ... We have some three Pull Requests on it.
21:05:23 [Bert]: ... One is blocked on darkmode.
21:05:46 [Bert]: ... And 23 issues.
21:05:56 [Bert]: ... Last update was posted in March.
21:06:53 [addison]: action: xfq: perform review of issues for inclusion in specdev
21:06:56 [gb]: Created -> action #128 https://github.com/w3c/i18n-actions/issues/128
21:07:20 [addison]: https://github.com/w3c/i18n-glossary/
21:08:09 [addison]: https://github.com/w3c/i18n-glossary/issues/13
21:08:09 [Bert]: addison: Issues on glossary.
21:08:09 [gb]: https://github.com/w3c/i18n-glossary/issues/13 -> Issue 13 Proposal to add "Detailed reading mode" (by murata2makoto) [wontfix]
21:08:31 [Bert]: ... Close it?
21:09:22 [Bert]: atsushi: I agree with xfq's comment on the issue.
21:09:52 [Bert]: ... I thint it was originally related to a11y.
21:10:11 [Bert]: s/thint/think
21:10:48 [Bert]: ... But no activity on it. So I agree to close with a wont-fix.
21:10:59 [Bert]: eemeli: Is this specific to Japanese?
21:11:03 [Bert]: atsushi: I think so.
21:12:34 [Bert]: addison: Is it used in jlreq?
21:13:14 [Bert]: atsushi: I don't think so. And I don't think there is an a11y glossary.
21:14:04 [Bert]: xfq: It is a way to explain in which ideograph is meant if two sound the same.
21:14:12 [Bert]: s/ in //
21:15:08 [addison]: https://github.com/w3c/i18n-drafts/pull/581
21:15:08 [gb]: https://github.com/w3c/i18n-drafts/pull/581 -> Pull Request 581 Initial work on language-negotiation materials (by aphillips)
21:15:24 [addison]: https://github.com/w3c/i18n-drafts/pull/581/files?short_path=7aef4dd#diff-7aef4dd22d30f6ded58eb6eb22421d27f49dbe36c5fc03a27352050d52590dab
21:15:28 [Bert]: i/xfq/addison adds wontfix label.
21:16:05 [Bert]: addison: 581 needs some stiing down. Comments welcome.
21:16:15 [Bert]: s/stiing/sitting
21:16:24 [addison]: agenda?
21:16:31 [addison]: zakim, take up agendum 7
21:16:31 [Zakim]: agendum 7 -- date/time pr -- taken up [from addison]
21:17:11 [xfq]: https://github.com/w3c/i18n-drafts/pull/327
21:17:11 [gb]: https://github.com/w3c/i18n-drafts/pull/327 -> Pull Request 327 Add info about HTML and JS new features (by xfq)
21:17:16 [xfq]: https://deploy-preview-327--i18n-drafts.netlify.app/questions/qa-date-format.en
21:17:58 [Bert]: xfq: Last time I showed this, addison said he wanted to review it. I replied to his comments.
21:19:37 [Bert]: addison: In first para, mm/dd/yy is not unique to the USA.
21:20:59 [Bert]: ... First para should explain the purpose of the article.
21:21:11 [Bert]: ... It is part of a Q&A?
21:21:18 [jyasskin]: https://shoelace.style/components/format-date/ and https://github.com/github/relative-time-element
21:23:10 [Bert]: present+ jeffrey_jaskin
21:23:34 [Bert]: jyasskin: Want to talk about new custom elements for date/time?
21:23:59 [Bert]: xfq: We can split the article.
21:24:21 [Bert]: addison: Or omit the parts we don't really talk about. E.g., storage.
21:26:12 [Bert]: ... Easy sorting may be a reason for a format.
21:26:46 [Bert]: ... Why is the accept-language header mentioned in the article?
21:29:02 [xfq]: rrsagent, make minutes
21:29:04 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
21:29:20 [Bert]: eemeli: It mentions accept-language, but not the lang of the HTML element.
21:31:18 [Bert]: addison: You can format a date at the server or at the client. The server would choose the format to match the rest of the page. The client side relies on Javascript.
21:32:14 [Bert]: xfq: OK, so I need to rework the text and make the scope and the intention more clear.
21:32:25 [xfq]: rrsagent, make minutes
21:32:26 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html xfq
21:33:04 [Bert]: eemeli: The user input examples show different formats. But they are not customizable, are they?
21:33:32 [Bert]: xfq: Correct, it depends on the browser.
21:35:23 [Bert]: xfq: You notice when you use somebody elses computer to enter a date...
21:35:55 [jyasskin]: https://open-ui.org/components/datepicker.research/
21:36:13 [Bert]: jyasskin: A survey about date pickers ^^
21:37:12 [Bert]: ... It doesn't look iike they have a proposal to improve this, but it is in their scope.
21:38:21 [Bert]: addison: CLDR covers almost all of the things in this article, even things like ‘today’ and ‘this week’.
21:41:26 [Bert]: addison: Different calendar for Thai is mentioned.
21:41:27 [Bert]: xfq: Issue of different calendars is not mentioned in the input section.
21:42:33 [Bert]: eemeli: And then there is the issue what is the ‘weekend’, it may be Fri-Sat.
21:43:25 [addison]: s/Fri-Sat/Fri and Sun/
21:46:29 [Bert]: eemeli: One option for is also to not choose a format, but use the HTML input element and let it choose it for you.
21:46:36 [Bert]: s/ for //
21:47:47 [Bert]: eemeli: It seems the document doesn't do itself what it recommends.
21:48:19 [Bert]: ... Who exactly is this document for? Maybe instead of spending time on it, drop it?
21:48:39 [Bert]: xfq: It is for display of dates. I added the input section.
21:49:07 [addison]: https://github.com/whatwg/html/issues/2404
21:49:07 [gb]: https://github.com/whatwg/html/issues/2404 -> Issue 2404 A tag to display date and/or time to the user in his preferred format. (by lostmsu) [addition/proposal] [needs implementer interest] [i18n-tracker]
21:49:32 [Bert]: ... Trying to update with some recent HTML5 and Javascript [since the document is from 2003]
21:51:13 [Bert]: addison: The WhatWG has an issue for a tag to display a date or time, ^^
21:51:33 [Bert]: ... It's on our list of things to discuss with them.
21:52:21 [Bert]: eemeli: The alternative to that is to use Javascript.
21:53:21 [xfq]: HTML time element -> https://html.spec.whatwg.org/multipage/text-level-semantics.html#the-time-element
21:53:23 [Bert]: There is a <time> element in HTML5. What is the relation?
21:54:41 [addison]: https://html.spec.whatwg.org/#the-time-element
21:54:44 [xfq]: datetime attribute: https://html.spec.whatwg.org/multipage/text-level-semantics.html#attr-time-datetime
21:55:29 [Bert]: Bert: I use the <time> elements in the TPAC pages, with Javascript.
21:55:53 [addison]: <footer>Published <time itemprop="published" datetime="2009-08-29">two days ago</time>.</footer>
21:56:36 [Bert]: xfq: So the <time> element can be used as a hook for Javascript.
21:57:33 [Bert]: eemeli: So an alternative could be to make the <time> element itself work.
21:58:17 [Bert]: addison: Yes, the issue 2404 mentions it, but it is not a complete proposal.
21:59:04 [Bert]: xfq: There could be similar elements for formatting numbers...
21:59:49 [Bert]: addison: And for telephone numbers…
22:02:28 [Bert]: Discussion about frustrating input forms that accept, or not, spaces, -, +, etc. in phone numbers. Or do not accept international phone numbers.
22:03:47 [Bert]: eemeli: Leaving it to the browser via a dedicated input control might avoid many user's problems.
22:05:03 [Bert]: addison: Input elements for different data types and output for different data types makes some sense.
22:05:56 [addison]: action: addison: ping shane carr about semantic skeletons as they relate to html
22:05:58 [gb]: Created -> action #129 https://github.com/w3c/i18n-actions/issues/129
22:06:18 [Bert]: eemeli: Short hop from having it in HTML and getting it in Javascript.
22:06:31 [Bert]: s/ and / to /
22:07:35 [Bert]: addison: Skeletons exist in a way in ICU.
22:08:12 [Bert]: ... Semantic skeletons are a limited number, not a configurable picture string.
22:08:59 [Bert]: ... I'm a fan, translators don't need to translate them, developers don't need to code.
22:09:26 [addison]: whatwg#4765
22:09:27 [gb]: Issue 4765 not found
22:09:38 [atsushi]: whatwg/html#4765
22:09:38 [gb]: https://github.com/whatwg/html/issues/4765 -> Issue 4765 The lang attribute and user input (by frivoal) [addition/proposal] [needs implementer interest] [topic: forms] [i18n-tracker]
22:11:07 [Bert]: xfq: dir attribute works, but lang cannot be set for user input.
22:18:32 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
22:20:02 [Bert]: eemeli: Still thinking about lang attribute on <input> and why it doesn't influence the input dialog.
22:20:37 [Bert]: ... That's not the same issue as 4765 above.
22:22:43 [Bert]: addison: Would supporting language ‘break the web’? Probably not.
22:24:08 [Bert]: eemeli: Should we file an issue on HTML5? Or is there one already?
22:24:49 [Bert]: Looking for related issues…
22:25:13 [addison]: https://github.com/whatwg/html/issues/9172
22:25:13 [gb]: https://github.com/whatwg/html/issues/9172 -> CLOSED Issue 9172 Make number's and <input>'s get along better (by )
22:25:42 [addison]: https://github.com/whatwg/html/issues/1014
22:25:43 [gb]: https://github.com/whatwg/html/issues/1014 -> CLOSED Issue 1014 Allow start day of week to be specified for <input type=date /> (by ) [addition/proposal]
22:26:43 [Bert]: addison: We may haved posed this question pre-GitHub.
22:27:25 [gb]: https://github.com/w3c/bp-i18n-specdev/issues/134 -> Issue 134 The state of components, follow the browser language or the node's language? (by xfq)
22:27:40 [Bert]: xfq: I think I filed an issue on specdev about this ^^
22:28:01 [addison]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17859
22:29:16 [Bert]: addison: I filed an issue in 2012 ^^
22:31:08 [addison]: https://www.w3.org/International/wiki/Locale-based_forms
22:31:50 [Bert]: xfq: Chromium had an issue, but it looks they didn't implement.
22:32:48 [atsushi]: rrsagent, this meeting spans midnight
22:37:02 [Bert]: -> https://html.spec.whatwg.org/multipage/input.html#input-impl-notes implementation note that suggests using the lang of the input element.
22:39:35 [addison]: https://html.spec.whatwg.org/multipage/input.html#number-state-(type%3Dnumber)
22:40:24 [atsushi]: firefox seems accept non-number characters? -> https://bugzilla.mozilla.org/show_bug.cgi?id=1398528
22:46:37 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
22:55:48 [addison]: Topic: webextensions
22:55:51 [addison]: https://github.com/w3c/webextensions/pull/569
22:55:51 [gb]: https://github.com/w3c/webextensions/pull/569 -> Pull Request 569 Proposal: i18n-system-languages (by carlosjeurissen) [topic: localization] [i18n-tracker]
22:59:21 [Bert]: Round of introductions.
23:00:51 [Bert]: Oliver_Dunk: Interested also in message-format.
23:04:08 [Bert]: ... We have some APIs, such as get_UI_language
23:04:23 [Bert]: ... That gets what the browser supports.
23:04:41 [Bert]: ... Goal is to get user's pref also.
23:05:31 [Bert]: calos_jeurissen: Goal is to split in getiing OS and user languages.
23:05:59 [Bert]: scalos_jeurissen/carlos_jeurissen
23:06:18 [Bert]: ... An extension can get more details for translation.
23:06:39 [Bert]: addison: There is a hierarchy among them?
23:07:39 [Bert]: rob_: Web developers can thus get the localization of the environment.
23:08:36 [Bert]: addison: It makes sense to use ‘language’ even though it is a locale, because all the other APIs also use the word ‘language’ and the attributes in HTML use ‘lang’, too.
23:09:44 [robwu[m]]: robwu[m] has joined #i18n
23:10:10 [robwu[m]]: Is this the right room?
23:10:20 [Bert]: eemeli: I get the reasons for this. But it sounds a bit like an expectation that the OS locale is a better approximation of the user's pref than the browser locale.
23:10:31 [Bert]: ... This is not always the case.
23:10:57 [Bert]: ... We did a test with German users of Sorbian.
23:12:04 [Bert]: carlos_jeurissen: That's why we split. In some OSs, the user can choose locales that the OS doesn't actually have translations for.
23:12:39 [Bert]: addison: Probably easiest to get is the runtime locale.
23:12:56 [Bert]: ... Whether the system is actually localized in that is harder to find out.
23:13:14 [Bert]: ... Sometimes locales are only partially installed.
23:13:25 [Bert]: ... E.g. Adlam on Android.
23:13:54 [Bert]: ... I'm curious about ‘preferred system languages’. How do you get that?
23:14:04 [Bert]: eemeli: MacOS has that.
23:14:49 [Bert]: addison: There is a third dimension: preferred inmput methods, keyboards and such.
23:17:27 [Bert]: xfq: Need to think about fingerprinting.
23:18:11 [Bert]: eemeli: TC32 discussed getting system language and decided not to open that possibility. But for an extension that is different.
23:19:41 [Bert]: ... How does getting preferred locale work on OSs that don't have that concept?
23:19:57 [Bert]: @@: We haven't thought that through.
23:20:22 [Bert]: rob_wu: @@ Firefox
23:20:41 [eemeli]: https://phabricator.services.mozilla.com/D206064
23:20:56 [Bert]: carlos_jeurissen: Question is how useful is the result, if it falls back to something.
23:22:07 [Bert]: eemeli: If there is a way to find the user's preferences, that is great, but if there is not, it is better not to guess.
23:22:26 [Bert]: rob_wu: in some cases getting any value is better.
23:22:46 [Bert]: @@: Falling back to the browser language seems reasonable.
23:23:59 [Bert]: eemeli: If both browser and OS say en or en_US, than reject that, and If it says something else, use it. en_US might just be the default...
23:25:25 [Bert]: ... When we looked at localized extensions for Firefox, there are few that are available in a locale that is neither the browser nor the OS locale.
23:26:16 [Bert]: eemeli: Why does the API return a Promise?
23:26:32 [Bert]: @@: We thought as it was a call to the OS.
23:26:49 [Bert]: rob_wu: By default we make APIs async.
23:27:06 [addison]: https://bugzilla.mozilla.org/show_bug.cgi?id=1888486
23:27:39 [Bert]: ... The latest proposed names are different from what is in the issue. Look at the implementation instead.
23:28:39 [Bert]: carlos_jeurissen: name is now getPreferredSystemLanguages.
23:29:07 [Bert]: atsushi: I can have both English and Japanese IME on the same system.
23:30:03 [Bert]: Are IMEs taken into account?
23:30:52 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
23:31:23 [Bert]: eemeli: I see a function that is synchronous, too.
23:31:43 [Bert]: That appears to be a mistake.
23:32:44 [Bert]: carlos_jeurissen: The names are also inspired by the Electron API.
23:33:01 [xfq]: Electron app.getPreferredSystemLanguages(): https://www.electronjs.org/docs/latest/api/app#appgetpreferredsystemlanguages
23:34:09 [Bert]: eemeli: I have some quibles, but oltherwise seems OK. Extensions don't have to worry about fingerprinting.
23:34:19 [Bert]: s/oltherwise/otherwise
23:35:50 [Bert]: @@: Apart from extensions, might able be useful for engines other than on the web, such as for Electron.
23:37:12 [Bert]: oliver_dunk: The Electron documentation has some descriptions.
23:37:52 [Bert]: rob_wu: But if our API will be different from Electron, then it is better to not use the same names.
23:40:41 [addison]: https://docs.gtk.org/glib/func.get_language_names.html
23:43:40 [Bert]: rob_wu: We implemented to always fallback to English, should we have intermediate fallbacks?
23:44:28 [Bert]: addison: Can fallback by stripping subtags: fr_FR, fr, en_EU, en
23:45:16 [Bert]: rob_wu: English, or whatever the default of the extension is.
23:46:34 [Bert]: addison: That fallback may not be available. The glib function g_get_language_names() adds the C locale at the end of the list.
23:47:32 [addison]: https://github.com/w3c/webextensions/issues/296
23:47:33 [gb]: https://github.com/w3c/webextensions/issues/296 -> Issue 296 `i18n.getMessage()` language fallback paths (by carlosjeurissen) [inconsistency] [topic: localization] [i18n-tracker]
23:48:51 [Bert]: eemeli: locales can be partial. Certain messages are translated and for the others you fall through. So data is not necessarily big.
23:51:48 [Bert]: addison: Download also reduced because you can typically cache. And not needed to keep all data: You build a map that contains the messages after all fallback and keep just that map.
23:54:16 [Bert]: eemeli: Firefox allows users to set preferred order of locales and it would make sense for extensions to use that user preference, too.
23:55:14 [Bert]: rob_wu: For interoperability good if all use the same way of fallback.
23:57:31 [Bert]: eemeli: Are all some user preferences part of a locale? Or can they be queried through a locale?
23:58:19 [addison]: cf. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/Locale
00:00:42 [Bert]: Returning strings or returning an Intl.Locale object?
00:01:03 [Bert]: rob_wu: We could add a function to get an Intl.Locale.
00:01:39 [Bert]: eemeli: Not needed. Just let the developer get a string and pass it to the Intl.Locale constructor.
00:07:08 [Bert]: addison: A user could override a locale and set a preference for, say Bengali digits, but that does not apply anymore if the locale falls back to English.
00:09:16 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
00:09:43 [Bert]: eemeli: Ben @1 of Igalia has been thinking about this. Shane Carr also.
00:09:53 [addison]: s/@1/Allen/
00:12:07 [Bert]: topic: message format
00:13:02 [Bert]: addison: Javascript Intl has to catch up. Message format can be useful for that.
00:14:06 [Bert]: ... We hope that people will make tooling when there is a single way, rather than many systems.
00:14:23 [Bert]: ... Message Resource.
00:15:59 [Bert]: ... A single format helps developers.
00:17:08 [Bert]: eemeli: Currently in TC39 discussion about message format 2.
00:17:52 [Bert]: ... CLDR TC has a working group that develops message format.
00:18:27 [Bert]: ... Working on messages in C++ and Javascript.
00:19:54 [Bert]: ... Probably an actual standard in 2025. Will take some time to get into Intl. But you can use getMessage API.
00:21:36 [Bert]: ... CLDR defines message format and what the result looks like as a single string. TC39 defines an API to access that.
00:22:13 [xfq]: https://github.com/unicode-org/message-format-wg
00:22:28 [Bert]: ... Message format for single messages is almost done.
00:24:04 [Bert]: addison: MessageFormat 2 will be part of ICU, so will be available for Java, C, etc.
00:24:28 [Bert]: s/message format/MessageFormat/g
00:24:37 [Bert]: s/Message format/MessageFormat/g
00:29:43 [addison]: MessageFormat@next on npm
00:30:23 [xfq]: https://github.com/messageformat/messageformat/tree/main/packages/mf2-messageformat
00:37:27 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison
00:42:30 [Bert]: More discussion in Web Extension meeting at 11:00 on Thursday.
00:43:02 [robwu[m]]: eemeli will create a prototype of MF2 usage in Firefox's i18n API, and asked whether Chrome's i18n API implementation entry point is also in JavaScript. The answer is no, Chrome's i18n implementation is [not in JavaScript any more](https://source.chromium.org/chromium/chromium/src/+/edf9d95aa61923672da1259415e628cf45f20dd8), but in C++. Chrome's source is at
00:43:02 [robwu[m]]: https://source.chromium.org/chromium/chromium/src/+/main:extensions/renderer/api/i18n_hooks_delegate.cc;drc=d209ffb065863b283fa0c3b7aec48f7f2471aba7.
00:43:20 [RRSAgent]: I have made the request to generate https://www.w3.org/2024/09/23-i18n-minutes.html addison