Feature(messageformat): Support locale to lang mapping in MessageFormatTranspiler

Current behavior

In our app we use EN, DE and FR languages. We have dedicated jsons for translations and also use corresponding locales. Also we have an empty json called ‘keys’ and it is our ‘keys’ language. This allows us to see the keys in the UI to help with translations.

Recently we added the locale support with transloco locale package, and also pluralization support with messageformatt. Overall it works as it should. But we lost the ability to show the keys in the UI.

After digging around I found that when we change the language from ‘en’ to ‘keys’, messageformat breaks with the error:

core.js:6479 ERROR Error: Localisation function not found for locale "keys"

This was weird because there is a setting option called langToLocaleMapping which should map ‘keys’ to the English values. For some reason that was ignored. So I went to sources and found out that MessageFormatTranspiler does this:

I got the feeling that the map is not used here because it is used in TranslocoLocaleModule, not TranslocoMessageFormatModule. And also setLocale(lang) seems wrong, at least naming wise.

Expected behavior

I’d expect MessageFormatTranspiler to resolve lang to locale and pass correct value to MessageFormat.

Minimal reproduction of the problem with instructions

Provide the STEPS TO REPRODUCE and if possible a MINIMAL DEMO of the problem, for that you could use our stackblitz example

Screenshots

If applicable, add screenshots to help explain your problem.

Transloco config

Environment

"@ngneat/transloco": "^2.23.0",
"@ngneat/transloco-locale": "^1.4.0",
"@ngneat/transloco-messageformat": "^1.3.1",
"messageformat": "^2.3.0",
 Angular version: ^12.2.5

Browser:

• Chrome (desktop) version 93
• Chrome (Android) version XX
• Chrome (iOS) version XX
• Firefox version XX
• Safari (desktop) version XX
• Safari (iOS) version XX
• IE version XX
• Edge version XX

Contribution

I would like to make a pull request for this feature: [x] Yes! 🚀 [ ] Maybe next time

[MikeDabrowski]

I guess I would not, unless hitting some language specific quirk that one locale handles better than other. Ok, so kick out the PR and keep setting language as locale. I overrode this on my end and things are again working as they used to. Im used to hitting the ‘1% cases’ errors 😁

[MikeDabrowski]

Let me explain my reasoning. My initial reaction when I read setLocale(lang) and saw the implementation was ‘it’s a bug’. And that is because the setLocale implementation had a parameter called locale but when it was used it received lang. In Transloco locale and lang are not interchangeable. Why should they be here? Then I went to messageformat and it turns out they resolve both lang and locale, from the same parameter.

Why shouldn’t I be able to pick whick lang uses which localized message format? Transloco already have the tools to allow for similar remappings, and I may not be far from the truth if I say most of the users using mf also do use TranslocoLocale.

In the end, I agree, I can handle this on my own just like you said.