-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Locale with upper case is resolved as used language but doesn't translate #1605
Comments
Cool, didn't know about that method yet. However if I understood it correctly this only configures the value returned from 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. |
I don't get it. The locale negotiation behind the scenes (i.e. via |
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). 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. In my opinion there are two solutions: |
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. |
Odd, apparently my JS changes didn't save properly. I have updated the plunker respectively. |
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. |
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). |
@Aides359 We would welcome your contribution :)
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
Too late in the flow, I think. |
I just realized that this is not as easy as first expected.
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) |
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:
angular.lowercase()
on each translation when getting the translation dictionaryIf you tell me the preferred solution I could create a PR.
The text was updated successfully, but these errors were encountered: