07:53:25 <RRSAgent> RRSAgent has joined #en-zz
07:53:29 <RRSAgent> logging to https://www.w3.org/2025/11/12-en-zz-irc
07:53:29 <breakout-bot> RRSAgent, do not leave
07:53:30 <breakout-bot> RRSAgent, this meeting spans midnight
07:53:31 <breakout-bot> RRSAgent, make logs public
07:53:32 <breakout-bot> Meeting: Defining a new Locale: Standard Measures with U.S. English
07:53:32 <breakout-bot> Chair: eemeli
07:53:32 <breakout-bot> Agenda: https://github.com/w3c/tpac2025-breakouts/issues/71
07:53:32 <Zakim> Zakim has joined #en-zz
07:53:33 <breakout-bot> Zakim, clear agenda
07:53:33 <Zakim> agenda cleared
07:53:33 <breakout-bot> Zakim, agenda+ Pick a scribe
07:53:34 <Zakim> agendum 1 added
07:53:35 <breakout-bot> Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy
07:53:35 <Zakim> agendum 2 added
07:53:35 <breakout-bot> Zakim, agenda+ Goal of this session
07:53:36 <Zakim> agendum 3 added
07:53:36 <breakout-bot> Zakim, agenda+ Discussion
07:53:36 <Zakim> agendum 4 added
07:53:36 <breakout-bot> Zakim, agenda+ Next steps / where discussion continues
07:53:37 <Zakim> agendum 5 added
07:53:37 <breakout-bot> Zakim, agenda+ Adjourn / Use IRC command: Zakim, end meeting
07:53:37 <Zakim> agendum 6 added
07:53:38 <breakout-bot> breakout-bot has left #en-zz
08:24:40 <hsivonen> hsivonen has joined #en-zz
08:27:27 <tantek-projector> tantek-projector has joined #en-zz
08:30:23 <xfq> xfq has joined #en-zz
08:30:29 <xfq> present+
08:30:37 <xfq> present+ Bert
08:30:42 <xfq> present+ vivien
08:30:50 <xfq> RRSAgent, make minutes
08:30:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/12-en-zz-minutes.html xfq
08:31:15 <xfq> present+ eemeli
08:31:31 <xfq> present+ atsushi
08:32:40 <tantek> tantek has joined #en-zz
08:32:52 <benoit> benoit has joined #en-zz
08:32:57 <Bert> Bert has joined #en-zz
08:33:05 <xfq> present+ hsivonen
08:33:18 <michaelficarra> michaelficarra has joined #en-zz
08:33:32 <mvsamuel> mvsamuel has joined #en-zz
08:33:38 <mvsamuel> Scribing
08:33:50 <xfq> scribe: mvsamuel
08:33:50 <vivien> vivien has joined #en-zz
08:33:56 <mvsamuel> eemeli: There is an explainer with much more detail than we're getting to.
08:34:02 <xfq> explainer -> https://github.com/mozilla/explainers/blob/main/standard-measures-en-us.md
08:34:03 <mvsamuel> session goal: improve English language
08:34:04 <johanneswilm> johanneswilm has joined #en-zz
08:34:19 <mvsamuel> Because Americans got their first en-US is the default English.
08:34:25 <robwu> robwu has joined #en-zz
08:34:31 <saji> saji has joined #en-zz
08:35:02 <mvsamuel> Firefox usage data: many users go with default locale.  2/3 of the users using Firefox in the en-US locale are browsing from outside North America.
08:35:26 <xfq> RRSAgent, make minutes
08:35:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/12-en-zz-minutes.html xfq
08:35:34 <mvsamuel> The default experience is mediated through an American understanding of date formatting, temperature&mass units.
08:35:55 <mvsamuel> In almost all dimension in which there is variance, en-US is an outlier.
08:36:19 <mvsamuel> Goal: provide better experience for users who don't want to or are unable to modify their experience.
08:37:25 <michaelficarra> q+
08:37:30 <mvsamuel> A solution: define a new locale is the default for certain regions.  It uses US English textual content.  But it has a better i18n experience for date formatting, everything formatting is more readily understood.  Less weird.
08:37:31 <johanneswilm> q+
08:37:38 <mvsamuel> Working identifier: en-zz
08:38:06 <mvsamuel> "zz" is recognized already as "unknown region".   Not the only option, but is memorable.
08:38:26 <mvsamuel> Advancing two things:
08:38:26 <mvsamuel> - definition of this locale
08:38:26 <mvsamuel> - use this locale once it becomes available
08:38:27 <michaelficarra> why not zz-zz if there's actually no indicated preference for english?
08:38:54 <hsivonen> q+
08:39:39 <atsushi> atsushi has joined #en-zz
08:39:52 <mvsamuel> Want feedback.
08:39:52 <mvsamuel> Where is this problematic?
08:39:52 <mvsamuel> We are changing the default.  We do not want to break.
08:39:52 <mvsamuel> Do not change where we have hints that the person is in the US or is asking for en-US.
08:39:53 <mvsamuel> Japan is a specific example.  Both Japanese and en-US prefer Sunday as day 0 of the week.
08:40:58 <mvsamuel> But en-zz would default to Monday as the first day in a datepicker.  We need user research to figure out where exactly to roll it out, including Japan.  Would like feedback from audience.
08:41:36 <mvsamuel> No need for a new standard in the W3C.  But want other groups to be aware and to use the en-zz locale where appropriate.
08:41:47 <mvsamuel> Eventually this would make it into CLDR data tables.
08:42:05 <xfq> ack hsivonen
08:42:06 <Bert> scribeoptions: -implicit
08:43:33 <mvsamuel> hsivonen: why not zz-zz?  There are users not in the US who explicitly want US english.  The explainer has examples why.  Bug reports say that even people who explicitly pick en-US as the UI language are unhappy with unit representation.
08:44:32 <mvsamuel> Most people don't know how to enable en-zz.  If without this the first language in the language picker would be en-US, we would append en-zz based on signals.
08:44:36 <snek> snek has joined #en-zz
08:44:43 <michaelficarra> s/append/prepend
08:44:51 <mvsamuel> (thanks)
08:45:34 <carlosj> carlosj has joined #en-ZZ
08:46:19 <mvsamuel> Datepickers in the Danish.  Now that there are datepickers on the web, this would allow them to adapt to "week starts on Monday".   This leads to expensive mistakes: booking hotels for the wrong day.  Fahrenheit/Celsius leads to fewer and less expensive mistakes.
08:48:03 <mvsamuel> General agreement on SI units, but the first-day-of-week breaks that assumption.  Biggest risk: not solving date picker problem because SI units handled otherwise.
08:48:30 <mvsamuel> michaelficarra: en-zz would have all the fields set to most common worldwide.
08:49:08 <mvsamuel> eemeli: close but not quite.  Not always the most common.  Most standardized.   YYYY-MM-DD for date-time formatting even though it's not the most common.
08:49:09 <benoit> would it try to default to some ISO standard format?
08:50:35 <mvsamuel> hsivonen: In the explainer, CLDR 001 by doing ISO date format.  ISO first day of week is always Monday for 001.   Right now in 001, min days is not four.  Parallel debate whether it's good idea to have min days in 001.  Google calendar ran into trouble.
08:51:18 <mvsamuel> In all the locales where people care about week numbering, people use ISO week numbering.  Complaints went down for Google Calendar.
08:51:34 <mvsamuel> US people don't care but if they coordinate with a European better to use ISO week numbers.
08:52:34 <xfq> q?
08:52:51 <mvsamuel> eemeli: for people not familiar with CLDR rules, (echoes xfq note on) 001 is the region subtag for world.  150 is Europe.  159 LatAm.  Plays into inheritence.
08:53:32 <mvsamuel> michaelficarra: the English part is that as spoken in some part.
08:53:45 <eemeli> s/159/419/
08:53:48 <xfq> s/159 LatAm/419 for Latin America and the Caribbean/
08:55:13 <mvsamuel> hsivonen: there are some languages in CLDR: arabic with a paradigm split.  en paradigm.  If you  only have en and apply likely subtags, it expands missing subtags (MacOS does this de facto).  Other paradigm is British English paradigm.  001 -> en-GB.  Other regions are "owned" by one of those paradigms.
08:55:36 <eemeli> q?
08:55:45 <eemeli> ack michaelficarra
08:56:48 <mvsamuel> en-US is used out of locale a lot.  Moreso than any other locale.  Motivation: you don't care about which English, so we can't change spelling based on a heuristic.  It affects spellchecking.  Users would reject.  It has to tie to linguistic aspects.  Can for things that trigger on region -> 001 except for week numbering and date formatting.
08:56:49 <eemeli> ack johanneswilm
08:58:47 <mvsamuel> johanneswilm: ime, in the smaller Scandinavian countries, smaller than Germany, more people don't understand English.  Fewer bug reports available.  I hope this doesn't take away from being able to localize.  People from all over the world.  Come in with laptop from US.  Let that organization's webpage.  Sometimes the organization wants to mandate
08:58:47 <mvsamuel> a convention for week numbering.  Organization overrides for widgets like date-pickers.
08:58:47 <mvsamuel> It is not like that today.
08:59:01 <hsivonen> q+
09:00:01 <mvsamuel> eemeli: A server can specify locale for served page.
09:00:17 <mvsamuel> hsivonen: talking about different datepickers.  eemeli is talking about JS library case.
09:00:38 <xfq> overriding the data picker's locale is discussed at https://github.com/w3c/bp-i18n-specdev/issues/134
09:04:02 <mvsamuel> This anecdote about buying train tickets in Denmark.  Some JS library .  Common use case for buying train tickets in Denmark in English language, English speaker from nearby European country.  I, Finnish, buy tickets in English in Denmark.  Ties to browser locale, not system week information.  We could focus on fixing that first.  Always a risk of
09:04:02 <mvsamuel> solving a problem for users who think of Monday-starting-weeks, but somewhere on the stack is a US datepicker.  But for users who (maybe from Japan) think of weeks starting on Sunday.  Fingerprinting that thinks there is one bit to flip.  The week is the worst thing.  Anecdotally, an Aussie user doesn't care.   But for me it's the hardest problem,
09:04:02 <mvsamuel> even though I know.  But we shouldn't give this problem to Japanese users.
09:04:24 <mvsamuel> eemeli: Specifically on the JS date picker.
09:06:19 <mvsamuel> xfq: Currently the HTML standard recommends the user agent can customize date picker elements using the language.  Browsers don't implement that, so it uses the browser UI language.  We have an issue tracking to change that.  People would like to integrate i18n status of date picker with whole page.  Currently is separate.  If page is in different
09:06:19 <mvsamuel> language from user agent.  Not implemented, despite that non-normative spec note.
09:06:47 <mvsamuel> hsivonen: but again, the date picker still leads to expensive, misbooked travel and train tickets
09:07:12 <mvsamuel> johanneswilm, xfq: tell the browser implementors to implement the thing
09:07:24 <johanneswilm> q+
09:07:40 <xfq> ack next
09:07:41 <xfq> ack next
09:07:45 <mvsamuel> hsivonen: disagrees.  The browser date picker should use the (system?) locale preference.
09:08:13 <hsivonen> s/locale preference/first day of week setting/
09:08:25 <hsivonen> q+
09:08:38 <mvsamuel> johanneswilm: company website, one datepicker look and feel for the whole company.  I start going shopping, buying plane tickets for personal use, use my locale datepicker.  I currently have en-CA to get km for uber.
09:08:55 <mvsamuel> I would love en-zz.  I would like to have the same datepicker as rest of my organization.
09:09:07 <eemeli> ack next
09:09:46 <mvsamuel> hsivonen: the organization thing is tricky.  One reason users use en-US outside US.  You have people in your org who don't read the local language and people who do but also read English.  The IT department forces en-US on issued laptops.
09:10:19 <xfq> re system local pref vs node language, we're having a kind of similar thing in the payment specs as well, it is awkward if the message the merchant supplies doesn't match the language (and amount / currency display) in the sheet
09:10:23 <mvsamuel> But you would want different units.  The IT department should be able force another detail (units?)?
09:10:31 <xfq> s/local pref /locale pref
09:10:42 <mvsamuel> (thanks)
09:11:31 <snek> q+
09:11:57 <mvsamuel> johanneswilm: as long as the browser is not following the org locale so there is not miscommunication within the organization.  But for the external page.  They would commercially let the users choose the datepicker.
09:13:00 <mvsamuel> snek: About the company that wants to control the locale.  Can they not just implement a custom thing.
09:13:45 <mvsamuel> johanneswilm: no.  React components do really get complicated.  I've had to develop several.  It'd be nice if the browser one worked.
09:13:57 <mvsamuel> eemeli: that sounds interesting but potentially separate from en-zz work.
09:14:22 <mvsamuel> johanneswilm: I don't want en-zz to block the lang attribute on the date picker.
09:14:39 <mvsamuel> ???: why en-ww for "worldwide"
09:14:51 <mvsamuel> eemeli: "zz" already means "unknown region"
09:15:09 <mvsamuel> ???: what if we really want unknown english
09:15:11 <xfq> there is no 'ww' subtag in the IANA registry
09:15:23 <xfq> s/???: why en-ww for "worldwide"/robwu: why en-ww for "worldwide"
09:15:28 <mvsamuel> hsivonen: "ww" is in the unused space and we should not assign meaning to it.
09:15:55 <mvsamuel> eemeli: "ww" is unassigned
09:16:13 <mvsamuel> "ww" only means worldwide in English
09:16:13 <robwu> s/why en-ww for "worldwide"/why not en-ww for "worldwide"/
09:17:11 <mvsamuel> eemeli: pet peeve: what about off planet colonies?!?  "zz" is unknown, not limited to Earth.  Won't someone think of the Martians
09:17:11 <mvsamuel> hsivonen: shame on Earth
09:17:32 <hsivonen> s/shame on Earth/stay on Earth/
09:17:45 <mvsamuel> (sorry)
09:18:42 <mvsamuel> hsivonen: consider who manages this namespace.  Unknown region is in the ISO namespace and the justification is the en component on its own, the likely subtag operation -> US, and zz should inherit most stuff from 001.
09:18:51 <xfq> RRSAgent, make minutes
09:18:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/11/12-en-zz-minutes.html xfq
09:19:39 <johanneswilm> q+
09:20:06 <snek> q-
09:21:17 <benoit> q+
09:21:28 <xfq> ack johanneswilm
09:21:33 <mvsamuel> If we were to do en-zz we would need to put zz in the US english paradigm.  The en-GB paradigm was listed separately.  en-IN was not.  But due to a bug report, unenumerated regions are assumed to be in en-GB's paradigm.  For this to work with CLDR we'd need to put zz in the en-US paradigm.  If we didn't do "zz" we'd have to be in the private use
09:21:34 <mvsamuel> space; not impossible; but if we want to bikeshed what's there we should consider private use identifiers without existing CLDR semantics.
09:22:40 <mvsamuel> johanneswilm: If this really takes off, maybe the status of the US is different.  We want the standard English, without "y'all."   We can change our definition of standard English separate from US English.
09:23:37 <mvsamuel> hsivonen: we don't need to plan ahead for that.  We can mint new identifiers as needed.  en-zz relating to en-US, the overriding reason: people who are not to the US system of measures use en-US as the UI language disproportionately empirically.
09:24:13 <eemeli> q+
09:24:16 <michaelficarra> maybe Americans just do a lot of international travel 🤔
09:24:36 <mvsamuel> We change just the units that trigger on region.  We're not trying to change anyone's English UI language.  Any other opinion on the "best English" is irrelevant, as we just are trying to change measures.
09:24:41 <xfq> ack ne
09:24:44 <xfq> ack next
09:25:58 <mvsamuel> benoit: can we reserve en-zz?
09:25:58 <mvsamuel> eemeli: this is not the only use of "zz" so probably not.  It's not widely used, but there are other uses.  The meaning we assign might end up taking over as de facto.
09:26:20 <mvsamuel> hsivonen: what needs patching in CLDR for this to work?  Fairly small changes.  A good sign.
09:27:46 <mvsamuel> If we have a browser that exposes this?  What do websites do?  We need to run that experiment to see if it breaks the web.
09:27:46 <mvsamuel> But no need to involve the ISO assignment authority by minting something like "ww".
09:27:46 <mvsamuel> Browsers use CLDR.  Websites and JavaScript use the same data.
09:27:59 <mvsamuel> Meaning in CLDR should guide us.
09:29:06 <benoit> would it be better to prefer "unspecified" instead of "unknown" ?   i.e. "English with an unspecified region" (where "region" is not necessarily the right word there)
09:29:26 <michaelficarra> eemeli hasn't met a Scot
09:29:39 <benoit> LOL
09:29:42 <mvsamuel> eemeli: not thoroughly thought out: re "y'all" concern about US english.  We could phrase it as "source English" plus standard measures.  English variants are mutually intelligble.  Not terrible if en-GB was served as en-zz content.  That would be different what we have currently (in the explainer?).
09:30:11 <mvsamuel> ???: What about source other languages.
09:30:11 <mvsamuel> eemeli: only looking at en-zz right now.
09:30:52 <benoit> fr-ZZ could start a war
09:30:52 <mvsamuel> Fingerprintability is a concern, but not for en-US.  E.g. for nl-zz there is a more of a risk.
09:31:01 <johanneswilm> q+
09:31:06 <eemeli> ack
09:31:20 <eemeli> q?
09:31:25 <eemeli> ack next
09:31:37 <mvsamuel> hsivonen: everything other than en-US is a distraction.  Users just do not use other languages out of locale to anything like the same degree.
09:32:43 <mvsamuel> johanneswilm: support eemeli.  A car company or phone company (eg from China) banned in the US might pick another default English.  They might not have an en-US translation.  Maybe just have a note explaining why it's the source language.
09:33:11 <eemeli> ack next
09:33:12 <mvsamuel> If en-GB or en-IN as their source language.  No substantial disagreement.
09:33:20 <mvsamuel> A non-normative note would do.
09:34:47 <mvsamuel> hsivonen: Nokia did use en-GB as their source English.  No longer.  Users wanting to use en-US to get the untranslated form is an observed phenomenon.
09:35:55 <robwu> robwu has left #en-zz
09:38:40 <hsivonen> s/Users wanting to use en-US to get the untranslated form is an observed phenomenon./Users wanting to use en-US to get the untranslated form is one known reason why users choose to use en-US, but this addresses the general observed behavior that many users use en-US outside the U.S. context without getting too focused on any one of the multiple
09:38:40 <hsivonen> reasons./
12:51:59 <johanneswilm> johanneswilm has joined #en-zz
13:02:20 <benoit> benoit has joined #en-zz
13:53:54 <tidoust> tidoust has joined #en-zz
13:53:57 <tidoust> RRSAgent, bye
13:53:57 <RRSAgent> I see no action items