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

[Esaj]

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.

[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").

[Esaj <jason at jasondavies.com>]

Check LANGUAGES setting for language support

[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.

[Esaj <jason at jasondavies.com>]

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

[Esaj <jason at jasondavies.com>]

Handle sublanguages correctly

[Esaj <jason at jasondavies.com>]

The latest patch does the trick.

[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.

[hugo]

(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.