1376616 - Implement mozIntl.Locale API for locale data operations

Status: RESOLVED DUPLICATE of bug 1433303

(Core :: Internationalization, enhancement, P3)

Description

[Zibi Braniecki [:zbraniecki][:gandalf]]

There's an early proposal for Intl.Locale API that would help us with any locale related operations - https://github.com/tc39/ecma402/issues/106

I think we could start with a local mozIntl.Locale API that would help us now and be a prototype for the future ECMA402 API.

Comment 1

[Zibi Braniecki [:zbraniecki][:gandalf]]

Attachment: Bug 1376616 - Implement mozIntl.Locale API for locale data operations.

Review commit: https://reviewboard.mozilla.org/r/154744/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/154744/

Comment 2

[Zibi Braniecki [:zbraniecki][:gandalf]]

Comment on attachment 8883790 [details]
Bug 1376616 - Implement mozIntl.Locale API for locale data operations.

Stas,

Would you be able to give me feedback on this?

It's a revision of the proposal from https://github.com/tc39/ecma402/issues/106 with some early spec written at https://github.com/zbraniecki/proposal-intl-locale

I modified it a bit and would like to continue with this feature set rather than the one from the early proposal (I'll update the spec once we settle on the code here).

The proposal needs some more work and tests, but the core functionality is there.

Initially, my goal is to make it support operations such as:

```
let loc = mozIntl.createLocale(locale, {calendar: 'gregory'}).toString();
```

which would be useful for scenarios like a datepicker which should always use gregory calendar (see bug 1370086).

Of course the dataset will be limited until we move the code to spidermonkey and fetch it from CLDR.

Comment 3

[Staś Małolepszy :stas]

I wasn't able to get to this before I left on PTO, sorry. I'll take a look when I'm back the week of July 31st unless you find someone else to do it before then.

Comment 4

[Daniel Ehrenberg]

Comment on attachment 8883790 [details]
Bug 1376616 - Implement mozIntl.Locale API for locale data operations.

https://reviewboard.mozilla.org/r/154744/#review164560

Do you have any tests for this feature?

::: toolkit/components/mozintl/MozIntlLocale.jsm:29
(Diff revision 1)
> +      return [
> +        'buddhist', 'chinese', 'coptic', 'dangi', 'ethioaa', 'ethiopic',
> +        'gregory', 'hebrew', 'indian', 'islamic', 'islamic-umalqura',
> +        'islamic-tbla', 'islamic-civil', 'islamic-rgsa', 'iso8601',
> +        'japanese', 'persia', 'roc', 'islamicc'
> +      ].includes(value);

It would be a bit unfortunate to have this kind of duplication, given that the information is represented in ICU. However, I can't find a public API to do this query directly.

What you can do, though, is construct an instance of a relevant class, and look at resolvedOptions() to see whether it was used. There'd need to be a little bit of special logic for the ones that change when normalize, that's all. For performance, you could maintain a Set of previously validated calendars (probably when it's invalid, it's OK for that t obe slow).

::: toolkit/components/mozintl/MozIntlLocale.jsm:44
(Diff revision 1)
> +      return Array.every(
> +        v,
> +        c => c.codePointAt(0) > 64 && c.codePointAt(0) < 91
> +      );
> +    case 'hourCycle':
> +      return ['h12', 'h24'].includes(value);

I guess this should include h11 and h23, given recent spec changes (when it's implemented in SpiderMonkey).

::: toolkit/components/mozintl/MozIntlLocale.jsm:126
(Diff revision 1)
> +    }
> +
> +    for (let name in optionToKeyMap) {
> +      if (options.hasOwnProperty(name)) {
> +        let value = options[name];
> +        if (!IsOptionValueSupported(name, value)) {

Minor: would it make sense to call the setter here, rather than duplicating the setter code?

::: toolkit/components/mozintl/MozIntlLocale.jsm:133
(Diff revision 1)
> +        }
> +        this._subtags.set(name, value);
> +      }
> +    }
> +
> +    for (let name in optionToKeyMap) {

Why are these accessors defined on the instance rather than Intl.Locale.prototype?

Comment 5

[Daniel Ehrenberg]

Comment on attachment 8883790 [details]
Bug 1376616 - Implement mozIntl.Locale API for locale data operations.

https://reviewboard.mozilla.org/r/154744/#review166174

Comment 6

[Daniel Ehrenberg]

Comment on attachment 8883790 [details]
Bug 1376616 - Implement mozIntl.Locale API for locale data operations.

https://reviewboard.mozilla.org/r/154744/#review179408

Comment 7

[Zibi Braniecki [:zbraniecki][:gandalf]]

With Intl.Locale reaching stage 3, I'm going to dupe this bug to bug 1433303 which is about implementing a public Intl.Locale.