Opened 11 years ago

Closed 11 years ago

Last modified 10 years ago

#750 closed defect (fixed)

i18n should ideally respect the languages supported on a per-application basis

Reported by: Esaj Owned by: hugo
Component: Tools Version: 0.90
Severity: minor Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


What if my main site application is only available in 'de' and 'en' translations, but the user's Accept-Language header is set to 'ru', 'de' (in that order)? Instead of using 'de' it will fall back to 'en'. This is because 'ru' is listed in LANGUAGES, so it sets the user language to 'ru'. However, there are no translation strings for 'ru' for the main site application, so it falls back to 'en'.

There needs to be some respect for which languages each application has support for, to solve this i.e. the set of supported languages should be considered per application. This is more of an enhancement request than a defect, since I can always change LANGUAGES to be what I want, e.g. ('de', 'en') in the above example.

Attachments (2) (2.1 KB) - added by Esaj <jason at> 11 years ago.
Check LANGUAGES setting for language support (3.3 KB) - added by Esaj <jason at> 11 years ago.
Handle sublanguages correctly

Download all attachments as: .zip

Change History (12)

comment:1 Changed 11 years ago by hugo

Changing LANGUAGES wouldn't do it, as LANGUAGES isn't used for the discovery - it's only there as a place for you to look for available languages. The language discovery actually uses the Django locale path for checking wether a language is available or not.

So I think as a first measure the function 'check_for_language' in django.utils.translation should check against the LANGUAGES setting, not against the django locale path as it currently does. And then you should set the LANGUAGES to the languages you would allow for selection. This would be consistent and would be a much better solution than language-selection per application - there are far too much things in Django that are view functions but not bound to any application (think "generic views").

Changed 11 years ago by Esaj <jason at>

Check LANGUAGES setting for language support

comment:2 Changed 11 years ago by anonymous

  • Owner changed from adrian to anonymous
  • Status changed from new to assigned

comment:3 Changed 11 years ago by hugo

  • Owner changed from anonymous to hugo
  • Status changed from assigned to new

comment:4 Changed 11 years ago by hugo

  • Status changed from new to assigned

comment:5 Changed 11 years ago by hugo

Esaj: did you check your patch against handling of sublanguages? If a user requires de-at, she should get 'de', even though it's not in the LANGUAGES in the settings. With the current way in trunk, that is done automatically by the gettext stuff. But if you change that over to using the LANGUAGES, you would need to do the sublanguage handling yourself, I think.

comment:6 Changed 11 years ago by Esaj <jason at>

No, the patch doesn't work properly for sublanguages. I'll try and fix it if I get time today...

Changed 11 years ago by Esaj <jason at>

Handle sublanguages correctly

comment:7 Changed 11 years ago by Esaj <jason at>

The latest patch does the trick.

comment:8 Changed 11 years ago by hugo

Actually it doesn't, as you got it backwards: not the supported languages need to be enhanced by the prime languages, but the user-requested language must be checked both for the requestes sublanguage and the requested main language ;-)

Additionally your patch got confused with language-codes and locale-codes (no worry, that's confuzzling me all the time myself)

But I have a fix for this, will go in with the next commit. The language selection now will be tuneable by setting LANGUAGES in the project settings file. Only those languages listed there can be selected. It will still be bound to languages provided as base languages for Django, though - so you won't be able to select a language that's not in django core. But then, selecting it without having at least a language file in django core really doesn't make much sense. In those rare situations where it would make sense, it could easily be "faked" by just copying over the english .po into the new locale directory to make the language selection happy.

comment:9 Changed 11 years ago by hugo

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [1204]) fixes #750 - languages for language-selection can now be restricted by setting LANGUAGES in the projects setting file to some subset of the global_settings provided list.

comment:10 Changed 10 years ago by anonymous

  • Component changed from Translations to Tools
  • priority changed from normal to highest
  • Severity changed from normal to minor
  • Type changed from enhancement to defect
  • Version set to 0.9
Note: See TracTickets for help on using tickets.
Back to Top