Regionalization/Localization

[kitsonk]

@kitsonk commented on Wed Jul 06 2016

Not all features of internationalization are just languages and RTL/LTR input and display. There are also other considerations like constructs like like dates, times and numbers (possibly more). What other features are needed and how should they be expressed?

---

@mwistrand commented on Thu Jul 07 2016

The only other use cases that come to mind are week definitions (does the week for the current locale begin on Sunday, or another day?) and locale-sensitive sorting (i.e., string comparison). However, my immediate suspicion is that implementing a shim for Intl.Collator and String.prototype.localeCompare (where the locales/options arguments are not supported) is nowhere close to "simple" (see below). That said, I do think we can provide reasonable shims for Intl.DateTimeFormat and Intl.NumberFormat, as well for the Date and Number localization methods in environments that do not support the additional locales and options arguments.

In this particular case, the shims for Intl and the localization-specific Date.prototype and Number.prototype methods would be housed under the dojo-shim repo instead of the dojo-i18n repo. It's also worth noting that dojo-core/DateObject would need to be updated to use these shims.

The Difficulty of Locale-sensitive String Comparison

Since a string can consist of any combination of any Unicode characters, any shim for String.prototype.localeCompare or Intl.Collator might have to load a significant portion of the Unicode definition for each locale, or at least contain complicated algorithms for determining the sort order for each locale. For example, providing the following requires at least a definition specifying that "a" and "á" represent the same base character (at least for the "en-US" locale) and locale-specific ordering:

'a'.localeCompare('á', 'en-US'); // -1
'a'.localeCompare('á', 'en-US', { sensitivity: 'base' }); // 0

This is a simplistic example, but the task becomes more daunting as the additional options (ignorePunctuation, caseFirst, the other sensitivity flags, etc.) are included. If anyone else has already looked into the possibility of an Intl.Collator shim, I'm interested to hear whether you reached the same conclusion.

[dylans]

Currency and number formatting were big ones in Dojo 1.x (e.g. commas vs. decimals, standard number of fractional units used, etc.)

[mwistrand]

Resolved by #28.