I’ve started implementation of the LocaleInfo class in Chrome and I would like to clarify what the actual parameters are and how do we construct the object given those parameters.
Differences to the current proposal are (for sake of simplification, but without any loss in clarity or functionality): - Combine languageNames and localeName parameters from the original proposal (0.5) into a single localeID parameter. - Leave currencyCode and currencySymbol as parameters for NumberFormat constructor. - LocaleInfo.options.regionID contains either user specified regionID or some inferred value (vs. only user specified value) one the LocaleInfo object is created. LocaleInfo constructor takes options parameter with two fields as input. - Optional: localeID - string or an array of unicode identifiers: [unicode locale id, ulocid,...]. We assume array is sorted by importance, from more to less important locale. LocaleID format is specified in UTS#35 document<http://unicode.org/reports/tr35/#Language_Locale_Field_Definitions> . - Optional: regionID - string representing region ID, used for currency inference and possibly other uses. The region ID values follow UTS#35 region subtag specification<http://unicode.org/reports/tr35/#Language_Locale_Field_Definitions>(ISO3166-1 specification with addition of invalid, undefined and reserved region codes). - If options parameter is missing, we set resulting localeID field to default** value. I propose algorithm <http://pastebin.mozilla.org/1198734> for resolving best match locale id and region id from inputs. We should discuss if actual distance computation for best match should be left to implementers or if we should standardize it (data it relies on may be different). As the product of the algorithm LocaleInfo object will have: - options.localeID set to a string that is a best match to available locales for given implementation and it will be in canonical form. At the minimum localeID will have base language subtag. In case localeID input was empty or we couldn’t find a match, localeID will have a default value. - options.regionID set to a canonicalized (uppercased) region ID. If one was not specified as an input, we store inferred value - either region subtag from original locale or most likely one using original locale if the region subtag is missing. Invalid/undefined/reserved codes are preserved. Examples - actual values may vary among implementations because of data variation. Implementers can also decide to pick different most likely locale (say en-GB instead of en-US) based on their target region... localeIDregionIDoptions.localeIDoptions.regionID--defaultdefault’s regionfr- frFRfr-CA-fr-CACAfrBEfr-BEBEfrRUfr (fr-RU is not available)RU[‘es’, ‘es-419’]-esES[‘pt’, ‘pt-BR’] PTpt-PTPTsrZZsr (didn’t match sr-ZZ, best match sr).ZZde-Latn-DE-u-co-phonebkATde-DE-u-co-phonebk (best match de-DE, and added extension)ATsr-MNBAsr-RS (didn’t match sr-MN, best match was sr-RS)BA ** - Implementation are free to pick the best default value for their platform. One possible default could be root locale. -- Nebojša Ćirić
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
