Meeting minutes
Agenda Review
<addison> #123
<gb> Action 123 reach out to the privacy person (Tara?) about meeting at TPAC (on xfq) due 2024-09-26
<addison> no reply yet
Planning for this week
<addison> https://
https://
<addison> https://
<addison> https://
ACTION: addison: propose creating a UTR for text-emphasis skip if we can get help with maintain
<gb> Created action #125
<addison> w3c/
<gb> 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]
https://
wikipedia uses lang="yue"
[Discuss whether :lang(zh-*) should match lang="yue"]
<addison> css selectors :lang match if their subtags match or if, after canonicalization, they match
RESOLUTION: (our intention is) css selectors :lang match if their subtags match or if, after canonicalization, they match
<r12a> i think Uzbekistan is currently in the process of changing from Cyrillic to Latin
<r12a> you may also find this app useful for some parts of this discussion https://
<r12a> https://
<addison> #1909
<gb> Issue 1909 not found
<addison> w3c/
<gb> Issue 1909 Should ACT require the formats for rules to be localizable? (by bert-github) [pending] [s:act-rules-format]
Bert: I found some editorial issues as well, but I"ll post to them directly
… ACT doesn't describe the specific format for rules
<addison> https://
Bert: it says you can use PDF or HTML
… they don't require that the human description is in a recognizable language
… it has to be plain language
… do we need to say that the format needs to be capable of labeling that language?
… unless that's implicit in being accessible
… assuming it's HTML, you can label
… but if it's another format, I don't know
xfq: what does they use the ACT rule for?
Bert: it's a format for storing accessibility checks
… it's not machine readble
… it's human readable
addison: you could build a machine readable thing around all of this
… but they don't require it
… @@
Bert: the format should not only be accessible but also be localizable
addison: by itself it's not wrong or right
addison: I think it would be good to say that they should have some text about providing localization
… even if it's not normative
Bert: OK
<addison> #1910
<gb> Issue 1910 not found
<addison> gb, help
<gb> addison, I am a bot to look up and create GitHub issues and
<gb> … action items. I am an instance of GHURLBot 0.5.
<gb> … Try gb, help commands or
<gb> … see https://
<addison> gb, repo
<gb> addison, sorry, I don't understand what you want me to do. Maybe try "help"?
<addison> gb, use
<gb> addison, sorry, I don't understand what you want me to do. Maybe try "help"?
<gb> Issue 1910 How are rule identifiers matched to one another? (by bert-github) [pending] [s:act-rules-format]
Bert: they have a rule Identifier
… they says this identifier must be unique
… but it is not specified how identifiers are compared
… or if they are normalized
… any recommendation?
addison: how does it enforce?
… charmod-norm
<addison> w3c/
<gb> Issue 1911 ACT does not require that the language of text is indicated (by bert-github) [pending] [s:act-rules-format]
Bert: It does not say anything about which human language
xfq: does "plain language" mean easily understandable language, or does it mean natural language?
Bert: I think it means easily understandable language
<addison> w3c/
<gb> Issue 1912 Is the ‘descriptive title’ used for matching? (by bert-github) [pending] [s:act-rules-format]
Bert: composite rule
… it refers to atomic rules with descriptive titles
… I don't know if the descriptive title is used for matching or searching
addison: in the EU they're gonna require at least 2 languages
<gb> CLOSED Issue 129 [AGWG] CR transition for ACT-Rules-Format (by nitedog) [Entering CR] [wg:ag]
ACTION: addison: check if ACT 1.0 was reviewed
<gb> Created action #126
<addison> w3c/
addison: reasonably soon, I'd like to consider transitioning string-meta to Note
… not just because I'm gonna go to the UTW workshop next month and talk about it
… we've done mostly the work on this
… we could look at buttoning up this spec being finished
https://
xfq: @@ see the process ^
addison: I think that would be good to have
… to say that this is our current thinking
… do others disagree?
[silence]
addison: I think most of our changes are in
… we have producers and consumers stuff
xfq: we have 15 open issues
https://
<addison> w3c/
addison: I've been working on an update to Working with time and time zones
<addison> https://
addison: formerly called Working with time zones
… I'd like to get this enough shape to publish the new one
… because I think it has a bunch of valuable information
eemeli: I have looked at it
… when reading it I did not get a sense of who is supposed to do what with this
addison: it's mostly directed at developers
… who need to work with time and time zones
… input type=time
… when do we get serialization
… mostly this is about if I'm writing a web page I should do X, I should not do X
addison: the sedate things are from RFC 9557
eemeli: proposed standard from April this year
addison: I would welcome comments
<addison> w3c/
<addison> w3c/
addison: string-search
… we have an open PR
<addison> https://
addison: stealing text from Henry
… we took all of the string search and find stuff out of charmod-norm
… that we could finish in our lifetime
… since then there have been at least 3 efforts to write down how find works
… in the browser
… including one that's currently incubating somewhere
<addison> https://
addison: in the bullet list ^
… if you search for each one of those words you can see what you would expect to find
… assuming that the string is tagged with the language properly
… obvious you can see what the browsers currently do
… the question is whether those are the things that they should do
… there was an attempt to make it use the collator
… you could type han, you could be lazy on inputting
… there's a feature for ignoring case
xfq: not just the UI, also the window.find() method
eemeli: any performance constraints?
addison: I'd like to finish the beta of this thing
… because we keep coming back to it every 3 or 4 years
… when somebody discovers that they want to write find
addison: Shane Carr reached out to me
Aki: Hi, I'm Aki Braun, former chair of TC 39
… I'm here on behalf of Ecma International Secretary
… I'm trying to figure out ways that our SDOs could be working together
addison: there's a steady stream of of API and additions and complications
… we want to develop in some sort of orderly fashion
… my other hat is the Unicode chair of MessageFormat
… it is ended up being effectively a templating language for strings
… what it really wants to have is a resource container
… the status of ES 10 years ago was not internationalized
… we're playing catch up
… in increasingly ordered and structred way
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
… it probably makes more sense from a message resource @@ defined somewhere other than TC 39
… I'll be at the UTW and have a session
… @@
Aki: TC 57
eemeli: I presume that's the next available number, yes
… the resource format is currently in this sort of uncomfortable space
… where we've done a small bunch of work
… but we don't know where technically this work
addison: I can tell you the number specs where people are revinting packaging
… 9 ways of doing this
… we can find one place to hold the best practices
Aki: we need to figure out that stuff not just for the web but broader than the web
… we as a group of SDOs like Unicode and W3C are sort of keeping an eye on what each other is up to
addison: how is the locale model implemented in HTML and looks like for JS
Aki: @@
addison: classical timekeeping, milliseconds since the epoch
… Temporal promises to solve that, but it exposes a bunch of these concepts which I'm not even sure if groups understand it
… I'm a little frustrated because it's a lot easier to work with people to teacher developers to use Temporal
addison: this group don't review all RFCs or Unicode work but we occasionally glance them
… we host some amount of article like material for explaining things and we use MDN
[Aki shows a document that says Ecma-W3Cliaison agreement on it]
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
Aki: @@
… when this come up we're gonna reach out to each other or schedule a joint meeting
r12a: I was actually gonna suggest something very similar
… could be that we put a reading list together
… things that we think we're working on, string-meta, for example
… time and time zones
… the other folks would be interested in
… and collaborating on
… if we had a page somewhere
… and then we could point to the documents where people could see what we're doing
addison: any actions we can take?
Aki: in the next few months, if you could come up with some areas where you think it would be relevant
… it would be helpful to talk to each other
ACTION: addison: make a list of shared topics of interest between TG2 and W3C-I18N
<gb> Created action #127
Aki: that could help me figure out things like how we could formalize relationships so that we could just have a joint meeting
addison: r12a is working on language enablement
xfq: @@
… like custom dictionary for text segmentation (like Intl.Segmenter)
<aki> shoot me an email at hi@akiro.se with any intersecting topic ideas
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
<r12a> https://
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"
… but without all the specific i18n aspects of American English attached
… what we've been kind of considering is specifically using a region code ZZ
… en-ZZ
r12a: wouldn't that just be en?
eemeli: the problem is that the web reality is that en translate to en-US currently
… and changing that to something else would break way too many things
Bert: in what way does it map to American English?
eemeli: week numbering is American rather than the ISO way of doing it
… weeks start on Sundays rather than Mondays
Aki: is this for historical reasons?
eemeli: this is a real world problem
… very clear majority of en-US localization of Firefox users are coming from outside the USA
… because that is the default effectively
… they chose English but what they end up getting is English with American
r12a: why leave the spelling in American spelling? because again my understanding is that most of the world uses British spelling for colour
addison: I think that's only partially true
<r12a> how about en-001
addison: 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
addison: @@
… CLDR adding every country code under English
… en-AQ
eemeli: if we use en-ZZ the sensible thing that would be to go with year-month-day
addison: the starting point would be the CLDR-TC
… whatever happens they have to manage the data for you
… es-419, nobody lives in 419
eemeli: you need to make Americans still get the American experience
addison: what do we call it? we already have International English
addison: en-IE, en-DE etc. differ only in a very small set of tailorable of the data
… usually not the dominant language of the country
… I don't know the solution, but @@ fallback
eemeli: 001 does not work because it's got an established practice
… it's already used by CLDR
… don't always work in all places
<addison> https://
<gb> Pull Request 569 Proposal: i18n-system-languages (by carlosjeurissen) [topic: localization] [i18n-tracker]
<addison> gb, status
<gb> addison, the delay is 15, issues are on, names are off, full issues are printed 10 at a time; and the repository is w3c/
<addison> w3c/
addison: Let's start with specdev.
… We have some three Pull Requests on it.
… One is blocked on darkmode.
… And 23 issues.
… Last update was posted in March.
ACTION: xfq: perform review of issues for inclusion in specdev
<gb> Created action #128
<addison> w3c/
<addison> w3c/
addison: Issues on glossary.
<gb> Issue 13 Proposal to add "Detailed reading mode" (by murata2makoto) [wontfix]
addison: Close it?
atsushi: I agree with xfq's comment on the issue.
… I think it was originally related to a11y.
… But no activity on it. So I agree to close with a wont-fix.
eemeli: Is this specific to Japanese?
atsushi: I think so.
addison: Is it used in jlreq?
atsushi: I don't think so. And I don't think there is an a11y glossary.
addison adds wontfix label.
xfq: It is a way to explainwhich ideograph is meant if two sound the same.
<addison> w3c/
<gb> Pull Request 581 Initial work on language-negotiation materials (by aphillips)
addison: 581 needs some sitting down. Comments welcome.
date/time pr
<gb> Pull Request 327 Add info about HTML and JS new features (by xfq)
https://
xfq: Last time I showed this, addison said he wanted to review it. I replied to his comments.
addison: In first para, mm/dd/yy is not unique to the USA.
… First para should explain the purpose of the article.
… It is part of a Q&A?
<jyasskin> https://
jyasskin: Want to talk about new custom elements for date/time?
xfq: We can split the article.
addison: Or omit the parts we don't really talk about. E.g., storage.
… Easy sorting may be a reason for a format.
… Why is the accept-language header mentioned in the article?
eemeli: It mentions accept-language, but not the lang of the HTML element.
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.
xfq: OK, so I need to rework the text and make the scope and the intention more clear.
eemeli: The user input examples show different formats. But they are not customizable, are they?
xfq: Correct, it depends on the browser.
xfq: You notice when you use somebody elses computer to enter a date...
<jyasskin> https://
jyasskin: A survey about date pickers ^^
… It doesn't look iike they have a proposal to improve this, but it is in their scope.
addison: CLDR covers almost all of the things in this article, even things like ‘today’ and ‘this week’.
addison: Different calendar for Thai is mentioned.
xfq: Issue of different calendars is not mentioned in the input section.
eemeli: And then there is the issue what is the ‘weekend’, it may be Fri and Sun.
eemeli: One optionis also to not choose a format, but use the HTML input element and let it choose it for you.
eemeli: It seems the document doesn't do itself what it recommends.
… Who exactly is this document for? Maybe instead of spending time on it, drop it?
xfq: It is for display of dates. I added the input section.
<addison> whatwg/
<gb> 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]
xfq: Trying to update with some recent HTML5 and Javascript [since the document is from 2003]
addison: The WhatWG has an issue for a tag to display a date or time, ^^
… It's on our list of things to discuss with them.
eemeli: The alternative to that is to use Javascript.
There is a <time> element in HTML5. What is the relation?
<addison> https://
datetime attribute: https://
Bert: I use the <time> elements in the TPAC pages, with Javascript.
<addison> <footer>Published <time itemprop="published" datetime="2009-08-29">two days ago</time>.</footer>
xfq: So the <time> element can be used as a hook for Javascript.
eemeli: So an alternative could be to make the <time> element itself work.
addison: Yes, the issue 2404 mentions it, but it is not a complete proposal.
xfq: There could be similar elements for formatting numbers...
addison: And for telephone numbers…
Discussion about frustrating input forms that accept, or not, spaces, -, +, etc. in phone numbers. Or do not accept international phone numbers.
eemeli: Leaving it to the browser via a dedicated input control might avoid many user's problems.
addison: Input elements for different data types and output for different data types makes some sense.
ACTION: addison: ping shane carr about semantic skeletons as they relate to html
<gb> Created action #129
eemeli: Short hop from having it in HTML to getting it in Javascript.
addison: Skeletons exist in a way in ICU.
… Semantic skeletons are a limited number, not a configurable picture string.
… I'm a fan, translators don't need to translate them, developers don't need to code.
<addison> whatwg#4765
<gb> Issue 4765 not found
<atsushi> whatwg/html#4765
<gb> Issue 4765 The lang attribute and user input (by frivoal) [addition/proposal] [needs implementer interest] [topic: forms] [i18n-tracker]
xfq: dir attribute works, but lang cannot be set for user input.
eemeli: Still thinking about lang attribute on <input> and why it doesn't influence the input dialog.
… That's not the same issue as 4765 above.
addison: Would supporting language ‘break the web’? Probably not.
eemeli: Should we file an issue on HTML5? Or is there one already?
Looking for related issues…
<addison> whatwg/
<gb> CLOSED Issue 9172 Make number's and <input>'s get along better (by )
<addison> whatwg/
addison: We may haved posed this question pre-GitHub.
<gb> Issue 134 The state of components, follow the browser language or the node's language? (by xfq)
xfq: I think I filed an issue on specdev about this ^^
<addison> https://
addison: I filed an issue in 2012 ^^
<addison> https://
xfq: Chromium had an issue, but it looks they didn't implement.
implementation note that suggests using the lang of the input element.
<addison> https://
webextensions
<addison> w3c/
<gb> Pull Request 569 Proposal: i18n-system-languages (by carlosjeurissen) [topic: localization] [i18n-tracker]
Round of introductions.
Oliver_Dunk: Interested also in message-format.
… We have some APIs, such as get_UI_language
… That gets what the browser supports.
… Goal is to get user's pref also.
calos_jeurissen: Goal is to split in getiing OS and user languages.
scalos_jeurissen/carlos_jeurissen
… An extension can get more details for translation.
addison: There is a hierarchy among them?
rob_: Web developers can thus get the localization of the environment.
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.
<robwu[m]> Is this the right room?
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.
… This is not always the case.
… We did a test with German users of Sorbian.
carlos_jeurissen: That's why we split. In some OSs, the user can choose locales that the OS doesn't actually have translations for.
addison: Probably easiest to get is the runtime locale.
… Whether the system is actually localized in that is harder to find out.
… Sometimes locales are only partially installed.
… E.g. Adlam on Android.
… I'm curious about ‘preferred system languages’. How do you get that?
eemeli: MacOS has that.
addison: There is a third dimension: preferred inmput methods, keyboards and such.
xfq: Need to think about fingerprinting.
eemeli: TC32 discussed getting system language and decided not to open that possibility. But for an extension that is different.
… How does getting preferred locale work on OSs that don't have that concept?
@@: We haven't thought that through.
rob_wu: @@ Firefox
<eemeli> https://
carlos_jeurissen: Question is how useful is the result, if it falls back to something.
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.
rob_wu: in some cases getting any value is better.
@@: Falling back to the browser language seems reasonable.
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...
… 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.
eemeli: Why does the API return a Promise?
@@: We thought as it was a call to the OS.
rob_wu: By default we make APIs async.
<addison> https://
rob_wu: The latest proposed names are different from what is in the issue. Look at the implementation instead.
carlos_jeurissen: name is now getPreferredSystemLanguages.
atsushi: I can have both English and Japanese IME on the same system.
Are IMEs taken into account?
eemeli: I see a function that is synchronous, too.
That appears to be a mistake.
carlos_jeurissen: The names are also inspired by the Electron API.
Electron app.getPreferredSystemLanguages(): https://
eemeli: I have some quibles, but otherwise seems OK. Extensions don't have to worry about fingerprinting.
@@: Apart from extensions, might able be useful for engines other than on the web, such as for Electron.
oliver_dunk: The Electron documentation has some descriptions.
rob_wu: But if our API will be different from Electron, then it is better to not use the same names.
<addison> https://
rob_wu: We implemented to always fallback to English, should we have intermediate fallbacks?
addison: Can fallback by stripping subtags: fr_FR, fr, en_EU, en
rob_wu: English, or whatever the default of the extension is.
addison: That fallback may not be available. The glib function g_get_language_names() adds the C locale at the end of the list.
<addison> w3c/
<gb> Issue 296 `i18n.getMessage()` language fallback paths (by carlosjeurissen) [inconsistency] [topic: localization] [i18n-tracker]
eemeli: locales can be partial. Certain messages are translated and for the others you fall through. So data is not necessarily big.
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.
eemeli: Firefox allows users to set preferred order of locales and it would make sense for extensions to use that user preference, too.
rob_wu: For interoperability good if all use the same way of fallback.
eemeli: Are all some user preferences part of a locale? Or can they be queried through a locale?
<addison> cf. https://
Returning strings or returning an Intl.Locale object?
rob_wu: We could add a function to get an Intl.Locale.
eemeli: Not needed. Just let the developer get a string and pass it to the Intl.Locale constructor.
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.
eemeli: Ben Allen of Igalia has been thinking about this. Shane Carr also.
MessageFormat
addison: Javascript Intl has to catch up. MessageFormat can be useful for that.
… We hope that people will make tooling when there is a single way, rather than many systems.
… Message Resource.
… A single format helps developers.
eemeli: Currently in TC39 discussion about MessageFormat 2.
… CLDR TC has a working group that develops MessageFormat.
… Working on messages in C++ and Javascript.
… Probably an actual standard in 2025. Will take some time to get into Intl. But you can use getMessage API.
… CLDR defines MessageFormat and what the result looks like as a single string. TC39 defines an API to access that.
eemeli: MessageFormat for single messages is almost done.
addison: MessageFormat 2 will be part of ICU, so will be available for Java, C, etc.
<addison> MessageFormat@next on npm
https://
More discussion in Web Extension meeting at 11:00 on Thursday.
<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, but in C++. Chrome's source is at