Mirrored pseudolocale (qps-plocm) is used for testing RTL. With a switch to Intl, we loose ability to pseudolocalize that, and Intl will pick en-US when it fails to recognize the language tag. The solution would be to inject 'ar' as a fallback for qps-plocm, so that Intl picks it. This way date/time in qps-plocm would be from 'ar' which better represents the actual scenario.

This may require us to switch Intl languages source from navigator.languages to document.l10n.languages

Thoughts?

If we need to change Intl anyways, maybe we should standardize qps-ploc and qps-plocm? Microsoft already usese these tags too, so there's some industry precedent. Ideally, Intl would know that qps-plocm is RTL and it could also know how to format things in it.

That would require extension to CLDR? Initially, I'd say that maybe if we centralizie Intl calls via a helper in bug 1191011, then we can alter the navigator.languages there? Or we could go for document.l10n.languages from l20n.js for Intl formatters and set 'ar' there as a second for qps-plocm. I'd still be interested in standardizing them, so I'm adding it to my bucket list of Intl API updates :)

This PR renames qps-ploc and qps-plocm to en-x-psaccent and ar-x-psbidib respectively, following Google's propsal at http://unicode.org/cldr/trac/ticket/3971.

Pike, flod -- I'm following Google here and I'd like to rename our pseudolocales to en-x-psaccent and ar-x-psbidi. The advantage is that we can then easily plug these codes into Intl and get something LTR or RTL, without any tweaking nor instrumentation. See http://unicode.org/cldr/trac/ticket/3971. What do you think about this change? Bug 1217733 has the Gaia part of the change.

What about "using Intl" means that we can't use qps? Generally, a ticket with no action for 4 years (basically) isn't a compelling lead to follow.

(In reply to Axel Hecht [:Pike] from comment #7) > What about "using Intl" means that we can't use qps? new Intl.DateTimeFormat(['qps-plocm']) means nothing to Intl, and it has no idea which language rules it should use. new Intl.DateTimeFormat(['ar-x-psbidi']) resolves to 'ar' meaning Intl can then use Arabic rules for displaying date and time. This is desirable for RTL testing since it's much closer to reality and shimming it with English rules is close to impossible.

I don't really have a strong opinion about this, even if I can see the benefit in using the new codes (no need to tweak them before passing to intl if it falls back correctly to Arabic and English). What was the reasoning behind the choice of current codes?

In the same spirit, I suggest we rename qps-ploc (Accented English) to fr-x-psaccent.