Spec questions/errors about proposal-intl-locale

[zbraniecki]

Is there an option for us to not support grandfathered tags at all?

[zbraniecki]

Do we want to restrict the input for Intl.Locale if certain Unicode extensions values aren't supported in Intl.{Collator, NumberFormat, DateTimeFormat}?

I don't think we want that. Intl.Locale is supposed to handle any bcp47 language tag string, not just the one we support in other formatters.

[anba]

#13 should fix all mentioned issues except for:

Step 3 should read:
If tag matches the langtag production and does not match grandfathered,
to cover the case of regular grandfathered language tags.

[littledan]

@anba My intention was to simply not support grandfathered language tags.

[anba]

Only irregular or also regular grandfathered language tags?

[littledan]

Oh sorry, I meant irregular grandfathered tags. So, the change you are suggesting seems important.

[anba]

Oh sorry, I meant irregular grandfathered tags. So, the change you are suggesting seems important.

Hmm, I'm a bit confused right now. The suggested change is only important if we also disallow regular grandfathered language tags.

[anba]

On second the possible restriction should probably use If tag matches neither the privateuse nor the grandfathered production, followed by Assert: tag matches the langtag production. instead of If tag matches the langtag production and does not match grandfathered,, because the former more clearly states the two unsupported productions.

[littledan]

I've tried to represent these questions on the agenda of the Intl call next Friday so we can get more input.

[anba]

There are at least two more issue with grandfathered tags:

1. If the input is a regular grandfathered tag without a modern replacement, appending Unicode extension sequences will create a non-valid language tag ("valid" in the sense of https://tools.ietf.org/html/rfc5646#section-2.2.9):

var loc = new Intl.Locale("cel-gaulish", {nu: "latn"});
print(loc.toString()); "cel-gaulish-u-nu-latn"

Since cel-gaulish-u-nu-latn no longer matches a grandfathered production, it has to be interpreted as a langtag language tag, which in turn means gaulish has to interpreted as a variant subtag. But gaulish is not a registered variant subtag, so the generated tag cel-gaulish-u-nu-latn is non-valid per RFC 5646.

While Intl.Locale in general doesn't care about non-valid language tags, we may still want to prevent generating non-valid language tags if the input itself was a valid language tag.

---

2. ICU uses its own replacement for grandfathered tags without modern replacements (and en-GB-oed).

• cel-gaulish → xtg-x-cel-gaulish
• zh-min → nan-x-zh-min
• en-GB-oed → en-GB-x-oed (Modern replacement available: en-GB-oxendict)
• i-default → en-x-i-default
• i-enochian → x-i-enochian
• i-mingo → see-x-i-mingo

As with the other grandfathered tags issues this shouldn't matter much in practice, because I don't expect that grandfathered tags are actually used in normal code.

[srl295]

@anba

en-GB-oed → en-GB-x-oed (Modern replacement available: en-GB-oxendict)

Good catch. filed IcuBug:13650

[littledan]

We discussed grandfathered tags at the last Intl meeting. The resolution, I believe, was to support regular and irregular grandfathered tags by mapping them each to modern tags, at the beginning of the process of parsing them. I believe this change was recommended for all of Intl, and not just Locale.

[littledan]

We've switched to Unicode BCP 47 Locale Identifiers, fixing the remaining issues.