Locale with upper case is resolved as used language but doesn't translate
See original GitHub issueWith 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.
Issue Analytics
- State:
- Created 7 years ago
- Comments:10 (5 by maintainers)
Top Results From Across the Web
Django Locale not working after deploying to server [ FIXED ]
I've just translated a site into Japanese & all it really needed was LANGUAGES and i18n_patterns . LocaleMiddleware will help do some magic ......
Read more >Language and locale resolution overview - Android Developers
For example, assume that you have the following situation: Your app's default language is en_US (US English), and it also has Spanish strings ......
Read more >9 biggest localization issues developers face (+ how to solve ...
1. Synchronizing translations between TMS and code repository. This task is probably the most common one for developers. We need to make sure ......
Read more >Internationalization: Understanding Locale in the Java Platform
Learn how to use locale-sensitive objects to customize your Java ... In contrast to the language codes, country codes are set uppercase.
Read more >Adding and Editing Locale Translation Strings - HL Vanilla ...
Vanilla is a fully localized application. That means that all parts of our user interface must be able to be translated.
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found

I don’t get it. The locale negotiation behind the scenes (i.e. via
determinePreferredLanguage()) is configurable withuniformLanguageTag(). However, if you apply a language explicitly, you are already in control. Where is the problem?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)