Add a way to remove subtags through options? about proposal-intl-locale

[littledan]

OK, I made a fancy v2 label for this. I'll leave the issue open for future development.

[nciric]

ICU supports part of this with addKeyValue, where value is empty. We could allow:

var loc = new Intl.Locale('en-u-ca-gregory', {calendar: ''});
// loc.calendar would return ''

Similar (but harder to implement) could be done with region and script. But I am not sure we would want this - what if you have 'zh-TW' and blindly remove region? It would push user to 'zh' which is simplified version.

I would rather implement minimize and maximize methods, or provide getters for language, script and region.

[littledan]

I'd like to express a strong preference for adding these in v2.

When we promoted the feature to stage 3, this indicated that we are done with it from a design standpoint and are ready to move to implementation. At the same time, we can present this method for a new staged proposal as early as the May TC39 meeting. Maybe it will even ship in browsers at the same time.

I'd like to limit additions to this proposal to things that are absolutely needed otherwise the other aspects of the proposal are broken.

[littledan]

@anba We could add a method for this.

Can you think of a case of needing it in an application? This could help guide the appropriate API shape.

Do you think this is a very core, common need? That would drive its inclusion in this proposal, as opposed to a follow-on proposal.

[anba]

Can you think of a case of needing it in an application? This could help guide the appropriate API shape.

Java's Locale.Builder allows to clear subtags, but when I was searching for Locale.Builder uses on GitHub most of the time only test or example code shows up. 😒 So I can't provide a definite use case for this functionality right now.

The mailing list and the design notes for Locale.Builder also don't provide any insights why Locale.Builder supports this functionality. Or rather, at least I didn't see any notes when skimming over the documents, but maybe I've just missed it.

Do you think this is a very core, common need? That would drive its inclusion in this proposal, as opposed to a follow-on proposal.

From what I've understood, this proposal aims to provide a minimal API surface for locales (e.g. it doesn't provide access to the variant and privateuse subtags or extension subtags besides some selected keywords for the Unicode extension subtag). And I'm okay with that approach, as long as we keep it extensible to be able to add more functionality in the future when needed. (Insert "Captain Obvious" image here. 😛)

So, if no one else shows up to support this functionality, I wouldn't be mad if we defer it and keep it out of the Locale v1 API.

[zbraniecki]

What would happen if you did:

let loc = new Intl.Locale("sr-Cyrl-SR", {script: ""});

I can imagine this returning sr-SR.

[nciric]

It's doable, but the question is - is it useful? It's easy to make mistake, by just turning off tags. I think that more useful approach is to expose method on Locale, say minimized("sr-Cyrl-u-ca-...") that would preserve -u- but give you sr- without region and script (or in case of zh-TW preserve region). пет, 6. апр 2018. у 15:20 Zibi Braniecki <[email protected]> је написао/ла:

…

What would happen if you did: let loc = new Intl.Locale("sr-Cyrl-SR", {script: ""}); I can imagine this returning sr-SR. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#16 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AD5iKh_he0QqgnWfSPvXycw62Gwk6bStks5tl-oUgaJpZM4R7j0S> .

[zbraniecki]

but the question is - is it useful?

Sure, I share your concern about people using it without understanding the consequences (removing CN from zh-CN), but I do see some use cases.

For example, in the language negotiation strategy we're using at Mozilla, one of the steps is to compare the list of available locales against the requested locale with some subtags cleared (in order to be treated as a range - en-*). We currently have private methods like locale.clearRegion() or locale.clearVariants() and once we switch to this API, I'd use the provided example to achieve the same.

Here's the documentation of our algorithm - https://searchfox.org/mozilla-central/source/intl/locale/LocaleService.cpp#378

[zbraniecki]

Hmm, actually, I think that minimize method would work even better here. So I'm totally ok going for that as @nciric suggests instead of some way to remove subtags.

[littledan]

@nciric I like the idea of minimize and maximize methods. Do you think we should do these in v1, or would it be OK to address in a follow-on proposal? As Intl.Locale I'd already at Stage 3, and it doesn't sound like those methods would require any changes to this proposal, just an additional, a follow-on proposal seems procedurally easier.

[nciric]

@littledan - what would be a product of minimize and maximize methods? A new locale object based on minimized/maximized form? Or just a locale string, that can be used to create new Locale object?

Either way, ICU provides trivial way of implementing both, so from that standpoint it can be part of v1.

We just need to make sure to curb feature creep into locale v1 - otherwise we'll never be done (just look at number of methods in ICU u_loc).

[zbraniecki]

a new Locale object imho.