Locale with upper case is resolved as used language but doesn't translate

[ScallyGames]

With a upper-case locale i.e. en-GB and lower case registered languages/aliases/wildcard aliases the locale negotiation is done lower-case only, on a match however the uppercase input locale is used.

On translation the exact set locale (case sensitive) is used to determine the used dictionary and as the dictionary is defined with a the lower-case key the dictionary is not found and the fallback translation is used instead.

As far as I see it there are two possible solutions:

• On locale negotiation use the lower-case as the set locale
• Call angular.lowercase() on each translation when getting the translation dictionary

If you tell me the preferred solution I could create a PR.

[knalli]

Have a look here: https://angular-translate.github.io/docs/#/api/pascalprecht.translate.$translateProvider#methods_uniformlanguagetag

[ScallyGames]

Cool, didn't know about that method yet.

However if I understood it correctly this only configures the value returned from .determinePreferredLanguage(), right?

Furthermore, I think the problem I have described above is rather a general problem, since a language tag is accepted as a valid tag matching the defined languages but then does not resolve to the correct translation.

[knalli]

I don't get it. The locale negotiation behind the scenes (i.e. via determinePreferredLanguage()) is configurable with uniformLanguageTag(). However, if you apply a language explicitly, you are already in control. Where is the problem?

[ScallyGames]

Okay, I've just quickly put together a plnkr (https://plnkr.co/edit/uCxtKi?p=preview) demonstrating the problem (note that I've just put together this language setup scenario).
Just click on English (en-US) and then English (en-GB) - what you will see is the spanish translation although the language is set to English.

This is due to https://github.com/angular-translate/angular-translate/blob/master/src/service/translate.js#L164 matching the lower-case preferred locale with the available locales successfully but then returning preferred (uppercase) instead of locale (lowercase) in L165.
Because of that the locale is set to en-US and then when translating in https://github.com/angular-translate/angular-translate/blob/master/src/service/translate.js#L1547 it tries to access $translationTables['en-GB'] which is undefined (in contrary to en-gb which would be defined). Since no translation table for the locale is found the next language form the fallback stack is taken.

In my opinion there are two solutions:

• Alter L165 to return locale instead of preferred
• Alter L1547 to get $translationTable[angular.lowercase(uses)]

[tspaeth]

When clicking on en-US or en-GB -- nothing is happening here and the keys are shown - and this is correct, as the system doesn't know anything about a fallback stack in your plunkr?!

Also one suggestion: Try to use the latest angular-translate library versions in your examples to cut out any other (already fixed) issues.

[ScallyGames]

Odd, apparently my JS changes didn't save properly.
Also you are right about updating (I just took some random template I could find), however the issue also applies to the current version.

I have updated the plunker respectively.

[tspaeth]

just a quick fix - if you change your mapping on the registerAvailable... from "en-gb" to sth like "english" and register it accordingly - all mappings will work.
Yes, somewhere the detection/mapping fails currently in this special case due to lowercase or matcher.

[ScallyGames]

I did realize that, still I expect it to be rather common to register the languages on their language tag and since any situations where the registered language matches the used language when comparing case insensitive but not when comparing case sensitive cause this problem (strangely enough no one seems to have experienced this problem before) it's probably better to fix this before anyone else runs into it.

Also as I said, the proper fix to this is really simple, however I am not absolutely sure if it has any side-effects (if you tell me which solution is preferred I wouldn't mind creating a PR for it).

[knalli]

@Aides359 We would welcome your contribution :)

Alter L165 to return locale instead of preferred

This would ensure not the requested but the actual used locale. I think that's fine. We have already some tests, but adding one test more covering this specific situation would make the PR more worth in addition

Alter L1547 to get $translationTable[angular.lowercase(uses)]

Too late in the flow, I think.

[ScallyGames]

I just realized that this is not as easy as first expected.

This would ensure not the requested but the actual used locale.

This is actually not the case - while this is true with language keys registered in lower case, it breaks on any other configuration (however this is not due to the proposed change but also in current production code)