13

I would like to have a few different versions of the same language in Django, customized for different countries (e.g. locale/en, locale/en_CA, locale/en_US, etc.). If there is no language for specific country I would expect to use the default language version (locale/en)).

Then in the settings file for each site I specify LANGUAGE_CODE and LANGUAGES.

For some reason, even if I specify the following settings, the locale/en_US translations are still used:

LANGUAGE_CODE = 'en'
LANGUAGES = (
    ('en', ugettext('English')),
)

Though I clearly specify that the language code should be en (not en-us).

Am I missing something? Already tried to find the answer in multiple places, including Django documentation.

Jordan Jambazov
  • 3,460
  • 1
  • 19
  • 40
  • Actually, if Django supports it, you'd want to maintain minimal entries in en_CA, en_US etc and fallback case-by-case on main *en* most of the time, because most words are the same across all flavors. I.e. pick from the specific if you find a word in it *neighbour* vs *neighbor* but leave *house* in main only. – JL Peyret Sep 23 '16 at 16:29
  • That's correct, but the problem is Django for some reason uses "en_US", even if I simply specify "en". Any clues? Edit: if I specify "en-ca", it properly uses "en_CA". – Jordan Jambazov Sep 23 '16 at 16:36
  • No, unfortunately this bit of advice came from my experience on another system and was just a pointer to keep your translation costs down. Haven't used Django translation support yet. – JL Peyret Sep 23 '16 at 20:20

3 Answers3

3

This is a quirk of Python (not specifically Django) and the gettext module.

Ticket 8626 was raised on the Django issue tracker around the time of the 1.0 release and after some suggestions and debate, the Django devs deemed it a "won't fix".

There are suggestions in the ticket thread to use 'en-en' as the default. My memory is a little rough but if I recall correctly this approach didn't play well with other parts of my i18n tooling (e.g. the pox library). I gave up and settled for using en-US as the default for the project and listing the other variants (e.g. en-au) as alternatives.

Dwight Gunning
  • 2,485
  • 25
  • 39
  • 1
    Thanks for giving a direction - bounty given to you! The thing is I am using i18n_patterns as well for having language customized URLs. The trick with "en-us" or "en-en" might work, but will change the URL structure of the application. Any suggestions for that? – Jordan Jambazov Sep 27 '16 at 21:32
  • Could you settle for having the en-US translations at both your general English (.../en/) and the US (.../en-us/) URLs? To be honest my preference is to keep language/locales out of the URLs but perhaps you can share your URL scheme in another question and I can give it some thought. – Dwight Gunning Sep 28 '16 at 05:11
1

A workaround to the issue would be to add following snippet to your settings.py file.

import locale
locale.locale_alias.pop('en', None)

Special credit to Venelin Stoykov who was able to investigate the behavior of the Python locale module.

Jordan Jambazov
  • 3,460
  • 1
  • 19
  • 40
0

may I suggest you to put a breakpoint into the LocaleMiddleware Class?

In this way, you might found out a clue which thing was actually getting your way from getting the right Language.

Becaue according the source code of LocaleMiddleware Class and the How Django discovers language preference , there could be so many things can affect the result.

bluebird_lboro
  • 601
  • 5
  • 17
  • Right, I am aware about that, but it is not the case, since I am using `i18n_patterns` and that's the first thing `LocaleMiddleware` is trying to look for. – Jordan Jambazov Sep 23 '16 at 01:37
  • Ok, I just tried adding breakpoints in the `process_request` and `process_response` methods of the `LocaleMiddleware`, and language the is correctly set to `en`. Even though, the `en_US` locale is used. – Jordan Jambazov Sep 25 '16 at 08:51