– DRAFT –
Internationalization Working Group Teleconference

Agenda Review

addison: added some agenda, anything else?

eemeli: want to add a localization proposal discussion

xfq: would add review comments

Action Items

<addison> https://github.com/w3c/i18n-actions/issues

<addison> #184

<gb> Action 184 reply to wcag issue with comment about doing a higher level of interaction and pre-review (on aphillips) due 2025-09-04

<addison> #135

<gb> Action 135 follow up on XR issue 1393 about locale in session (on aphillips) due 2024-10-17

<addison> #127

<gb> Action 127 make a list of shared topics of interest between TG2 and W3C-I18N (on aphillips) due 2024-09-30

<addison> #33

<gb> Action 33 Close issues marked `close?` or bring to WG for further review (on aphillips)

<addison> #7

<gb> Action 7 Remind shepherds to tend to their awaiting comment resolutions (Evergreen) (on aphillips, xfq, himorin, r12a, bert-github) due 18 Jul 2023

<addison> #4

<gb> Action 4 Work with respec and bikeshed to provide the character markup template as easy-to-use markup (on aphillips) due 27 Jul 2023

Info Share

jsahleen: one question-ish, spec review
… one comment on error interface. geolocation provide code and message, message only on English
… anything we need to flag on these?

addison: what we did and recommended is file an issue to our i18n-activity repository before filing to them, and see comment internally first
… file comment on procedure things to request issue

Review RADAR Review

<addison> https://github.com/orgs/w3c/projects/91/views/1

addison: new incoming from ECMA

eemeli: one reason I am here is to say this one is the first review request to i18n WG
… this one should be short
… is there anything we should coordinate for automation or else?
… like global labels or something else

addison: our automation is per repo, but we also have automation on our request tracking

r12a: for WHATWG they have labels

<gb> Issue 4562 Validating internationalized mail addresses in <input type="email"> (by jrlevine) [addition/proposal] [needs implementer interest] [topic: forms] [i18n-tracker]

<xfq> https://github.com/whatwg/html/labels?q=i18n

r12a: automation for trackers etc. are interesting question

eemeli: any one request will have one repository on our side, adding automation to single would not work

addison: we may provide multiple issues from review, automation with labels could be close interaction between two groups
… you could ask question without having issue, but just with adding label to issues in your repository
… one of agenda+ for today, you could notice that is coming from external repository
… having one repository per proposal could have fliction on automation, but we could discuss

eemeli: if it possible to setup tooling from your side?

ACTION: addison: follow up with PLH on automating TC39 repos

<gb> Created action #185

addison: who should be contact at your side?

<xfq> it's currently per-repo for non-w3c repos: https://github.com/w3c/github-notify-ml-config/blob/4801ee8ad26915b92dea5e965d1c7dc4d4f2edbc/mls.json#L815

[interaction in technically]

Pending Issue Review

<addison> https://github.com/w3c/i18n-activity/issues?q=is%3Aissue+is%3Aopen+label%3Apending

<addison> #2034

<gb> Issue 2034 not found

<addison> i18n-activity#2034

<gb> Issue 2034 Should `message` be localizable? (by aphillips) [pending] [s:geolocation]

addison: #2034, one joel said, will discuss later

<addison> https://www.w3.org/TR/geolocation/#message-attribute

jsahleen: do we have any policy over?

addison: basically we recommend to have lang and dir

<xfq> https://w3c.github.io/bp-i18n-specdev/#errors

addison: there is note on suggestion in best practices

<addison> w3c/i18n-activity#941

<gb> CLOSED Issue 941 suggest alternative text for description of GeolocationPositionError.message attribute (by himorin) [needs-resolution] [agreed-to-close-during-mtg] [s:geolocation] [t:loc_localization] [wg:das]

<addison> w3c/geolocation#50

<gb> CLOSED Issue 50 Change text for description of GeolocationPositionError.message attribute (by himorin) [i18n-needs-resolution]

jsahleen: close new one per current Note: was from our suggestion?

addison: in the end of issue #50, there is a comment about moving discussion into WebIDL

<gb> CLOSED Action 50 raise TAG request about reviewing string definitions (on aphillips) due 2023-10-12

addison: do we want to say it was fine at last moment? any suggestion?

r12a: did we close with agreement?

addison: it seems we closed our tracker also.

numeric character input

<addison> i18n-activity#2032

<gb> Issue 2032 Define normalization of full-width numeric characters in <input type=number> user input (by w3cbot) [tracker] [s:html] [spec-type-issue] [jlreq] [clreq] [i:interaction] [t:loc_numbers] [whatwg] [Agenda+]

<addison> whatwg/html#11616

<gb> Pull Request 11616 Define normalization of full-width numeric characters in <input type=number> user input (by kyouhei-horizumi) [normative change] [topic: forms] [i18n-tracker] [i18n-jlreq] [i18n-clreq]

addison: sometimes ago, we discussed about this point
… browser normalize and process as numeric
… Richard commented about digits from different writing system
… and comma with dot, minus sign etc.
… desire NFKC-ed input there
… in specific on comma/dot
… do we need to have custom list, or add nomalization layer
… rether than relying on cldr, html layer should have something?

addison: cldr have list of characters to be used

addison: will only work from point of view on language, but full width comma will stop parsing

<addison> １２３４．５６

<jsahleen> ，

<addison> ー１，２３４．５６

xfq: does EAW is a character property, there is no mapping

addison: cldr has bunch of data about separators

<r12a> Urdu also has special characters for the thousands and decimal separators: ٬U+066C THOUSANDS SEPARATOR and ٫U+066B DECIMAL SEPARATOR (see Figure 6), although the ASCII full stop and comma may also be used.

r12a: other language could have different characters

addison: might be in cldr also

<r12a> https://r12a.github.io/scripts/arab/ur.html#numbers

r12a: not managable from normalization

<jsahleen> From cldr-json for ja: https://github.com/unicode-org/cldr-json/blob/c883679ed17a36da8a3ebcc6b3f4994a9277f132/cldr-json/cldr-numbers-full/main/ja/numbers.json#L16

<addison> https://unicode.org/cldr/charts/48/by_type/numbers.symbols.html

jsahleen: looking into cldr data, there is some definitions

addison: there are several example characters

jsahleen: I could file issue or something, meeting are Wed

<r12a> https://github.com/unicode-org/cldr-json/blob/c883679ed17a36da8a3ebcc6b3f4994a9277f132/cldr-json/cldr-numbers-full/main/ar/numbers.json#L16

ACTION: jsahleen: file issue with CLDR and report progress related to east asian widths in html#11616

<gb> Created action #186

addison: full width is one of specific item

Use zxx in place of an empty daptm:langSrc

<xfq> w3c/dapt#322

<gb> Pull Request 322 Use `zxx` in place of an empty `daptm:langSrc` (by nigelmegitt) [agenda]

<xfq> https://pr-preview.s3.amazonaws.com/w3c/dapt/pull/322.html#text-language-source

xfq: discussed last week
… filed two issue
… one is validation and another is using zxx

addison: zxx represents to non linguistic content
… it's inconvinient for some text
… if you know content is not linguistic, use zxx

xfq: use empty if they don't know

addison: keeping empty means lack of information

r12a: empty also means not provided

<eemeli> tc39/proposal-stable-formatting

eemeli: not specific on this, but using zxx we have another proposal in TC39, challange that JS input library provide capability of localization
… and what should take when library does not provide
… use zxx for getting expecting predicted behavior by tooling
… use predicted value rather than specified

eemeli: context of zxx here might be any specific meaning here

addison: classically, locale is used for specifying behavior
… intl has large relationship with locale

addison: image could have zxx for non linguistinc, also could copy one from surrounding text

localization proposals discussion

eemeli: would like to make html better for i18n and l10n
… find this challanging on meta data level, don't know a good place to host this kind of discussion
… if can some group around W3C host these discussion, or some group could, I would want to hear

addison: you could open issue with i18n and whatwg related issue

addison: we already have several interaction issues in tracker

<eemeli> https://github.com/mozilla/explainers/blob/main/amount.md

<addison> i18n-activity#1645

<gb> Issue 1645 <input type="time"> : Time vs. duration (by w3cbot) [tracker] [s:html] [t:loc_time] [Agenda+I18N+WHATWG] [whatwg]

<addison> whatwg/html#5488

<gb> Issue 5488 <input type="time"> : Time vs. duration (by d-damien) [addition/proposal] [needs implementer interest] [topic: forms] [i18n-tracker]

[discussion about meta and overall discussion, where and how]

<xfq> whatwg/html#2404

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

eemeli: will consider and back to group shortly, and might have some breakout session during upcoming TPAC

addison: could be a joint meetings with other groups whose participants could be interested

AOB?

r12a: does anyone download new Mac OS?
… and try new feature?