Skip to content

Conversation

@eemeli
Copy link
Collaborator

@eemeli eemeli commented Oct 27, 2025

We should figure out what to actually do about u:locale, rather than just leaving it as Draft (as was done in February). My position is tending towards the feature not being sufficiently well motivated for the added complexity that it introduces. I'm relatively certain that the rare cases when it's actually needed it doesn't need a solution baked into the spec; this is also discussed on #976.

@aphillips
Copy link
Member

I obviously disagree with the "lack of motivation" argument. I get the argument from the ICU4X folks that it would be hard(er) for them to implement. But I have a reasonable amount of experience needing it for uses other than I18N demos (usually it is needed for tailoring locale options). Implementations that choose to implement this optional feature can make good use of it.

That said, leaving it in draft limbo is not helpful. It's either well-described and reserved for the specific use or we let implementations create namespaced versions for their own use. Probably better to do the latter if this won't be universally portable anyway.

Copy link
Member

@aphillips aphillips left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changes look complete.

@zbraniecki
Copy link
Member

I'm relatively comfortable with the assumption that I will be able to make it work in ICU4X, but it will require a double-pass approach which would be quite unfortunate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEEDBACK] u:locale may be problematic for ICU4X and interoperability

5 participants