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>

Attachment: added

Check LANGUAGES setting for language support

comment:2 Changed 11 years ago by anonymous

Owner: changed from Adrian Holovaty to anonymous
Status: newassigned

comment:3 Changed 11 years ago by hugo

Owner: changed from anonymous to hugo
Status: assignednew

comment:4 Changed 11 years ago by hugo

Status: newassigned

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>

Attachment: added

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: fixed
Status: assignedclosed

(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: TranslationsTools
priority: normalhighest
Severity: normalminor
Type: enhancementdefect
Version: 0.9
Note: See TracTickets for help on using tickets.
Back to Top