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

[MikeDabrowski]

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]

So the solution seems to be to inject LOCALE_LANG_MAPPING and use it to translate lang to locale in MessageFormatTranspiler.
LOCALE_LANG_MAPPING comes from transloco locale package. Can we use it here or not ? If not we can add the mapping to MessageFormatTranspiler options. @shaharkazaz I'd be grateful for any thoughts.

[shaharkazaz]

@MikeDabrowski Thanks for the detailed issue.
I do wonder, though, this is the first time this has been raised, and it's raised due to something you did in your project to help development mode (adding the keys lang).

I wonder if all of this is really necessary, you can resolve this issue on your half by extending the Messageformat transpiler and overriding the onLangChanged to handle your keys case.

Correct me if I'm wrong, but if you didn't have the keys lang, everything is working as expected for you.
What do you think? 🙂

[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.

[shaharkazaz]

@MikeDabrowski There is no dought that this is a useful feature if it's really needed as I said, would you need it if it wasn't for your keys lang?

Even if we do want to implement it I want to think of how should we do it, not sure I want the coupling that your PR shows between the locale and messageformat packages.

I think that for now, we will keep things as is, and if it's raised again in the future we can rethink this. 🙂

[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 😁