Define fallback behaviour in {Calendars,Collations,HourCycles,NumberingSystems,CharacterDirection,WeekInfo}OfLocale about proposal-intl-locale-info

[anba]

Or maybe even just define explicit fallback values instead of defaulting to und-001, that way it's more clear what to do in a (theoretical) implementation which doesn't even have locale data for und-001.

Operation	Default value
CalendarsOfLocale	"gregory"
CollationsOfLocale	???
HourCyclesOfLocale	"h23"
NumberingSystemsOfLocale	"latn"
CharacterDirectionOfLocale	"ltr"
WeekInfoOfLocale	{ [[FirstDay]]: 1, [[Weekend]]: « 6, 7 », [[MinimalDays]]: 1 }

collations seems to be a problem, because ICU4C returns the collations for the default locale when the input locale is unrecognised:

andre@andre-dev:~$ LANG=de opt/v8/d8 -e "print(new Intl.Locale('tlh').collations)"
emoji,eor,phonebk
andre@andre-dev:~$ LANG=fr opt/v8/d8 -e "print(new Intl.Locale('tlh').collations)"
emoji,eor

(When de is the default locale, there's an additional phonebk collation in the returned array.)

This seems a bit problematic to me.

[FrankYFTang]

I do not think we need to define the fallback behavior. The fallback is just part of the detail of how to decode locale data. Conceputally every locale has a value, the fact that the resource data in ICU does not explicit define them are just a memory optimization strategy to not duplicate the information when that information are the same as the fallback value. The fallback are just an implementation detail that CLDR define based on that data model. Conceptually each locale has every values, either explicitly encoded in the resources or implictly getting from the fallback.

[FrankYFTang]

@sffc @zbraniecki @ben-allen @gibson042 - any opinion?

[sffc]

TimeZone is exceptional because it impacts the rendered value of the data. The others are all preference-related, so it makes sense to use a CLDR fallback algorithm (which may do something such as looking up a value from likely subtags).

When no calendar information for locale is available, use the calendar identifiers in common use for the locale "und-001".

This situation, "when no calendar information for locale is available", is still fuzzy. The calendar is defined in CLDR by region, but it may be reasonable for th, not just th-TH, to infer the Buddhist calendar.

[sffc]

TimeZone is exceptional because it impacts the rendered value of the data. The others are all preference-related, so it makes sense to use a CLDR fallback algorithm (which may do something such as looking up a value from likely subtags).

When no calendar information for locale is available, use the calendar identifiers in common use for the locale "und-001".

This situation, "when no calendar information for locale is available", is still fuzzy. The calendar is defined in CLDR by region, but it may be reasonable for th, not just th-TH, to infer the Buddhist calendar.

[anba]

The input may not be a recognised locale, for example consider new Intl.Locale("xyz") (there isn't an ISO 639 code for xyz) or if no CLDR data is available (new Intl.Locale("egy-Egyh"), for Egyptian in Hieratic script). Most implementations will likely return "ltr" for new Intl.Locale("egy-Egyh").getTextInfo().direction, even though the correct answer should be "rtl".

So for bogus inputs or if no corresponding locale data is available, spec steps like:

[...] sorted in descending preference of those in common use for formatting numeric values in locale.

can't be applied, because neither the preference nor the common use can be determined.

---

Maybe there was a misunderstanding when I mentioned "fallback"? I didn't mean "fallback" to refer to some locale inheritance scheme, but instead what values should be used as the fallback when no data is available at all.