Showing results for 
Show  only  | Search instead for 
Did you mean: 

Governance issue with the Intl.DateTimeFormat implementation

Making moves

I would like to talk about the implementation of the ECMA-402 : Internationalization API Specification.

The spec defines the interface of `Intl` objects so browser can offer a unified interface. It also give guidelines about the implementation.

Recently I stumbled upon a weird behaviour. I asked `Intl.DateTimeFormat` to format a date with `numeric` days. And it wouldn't give me anything else than a `2-digit` format, unless I set the month format to `narrow`, `short` or `long`. (Try it yourself)

Intl implementation is built around CLDR data. It describes itself as `The new home of the Unicode Common Locale Data Repository`.
It's great to have a unified repository where we can find presets for date formats.

But my issue is that presets are nothing more than recommendations. The ECMA 402 itself describes interfaces that accept options to define the desired output.

Look at this bug report :
One of the comment is mortifying to me :

I believe this is not a bug, as the translator decision should override the developer decision from the components bag. If this is not correct, then I believe the proper place to fix this is in the CLDR translations.

The translator decision should override the developer decision

Have we not learned anything ? Maybe I'm not old enough but when overriding a developer's choice has been the right decision ? At best I'm willing to say it may have been a good thing in some security contextes, but even then I can only recall deprecation notices or warnings.

So my question to you reader is :

Should the Intl implementation still override the developer's format decision in the future releases of Mozilla Firefox ?

I believe it shouldn't, what do you think ?



I hadn't heard of this object before, and based on the MDN documentation, this almost certainly is over my head. I will just share that link here for context: