#1215 closed defect (invalid)
Locale finding is broken.
Reported by: | jiivan | Owned by: | hugo |
---|---|---|---|
Component: | Internationalization | Version: | |
Severity: | normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
Locale finding in function
django/utils/translation.py.get_translation_from_request()
looks only in globalpath unlike
translation()wich looks in all paths starting from PROJECTDIR. If the language isn't defined in django/conf/locale (i.e. pl) it returns None, altough it is defined in PROJECTDIR.
The only workaround I've found is to make a fake file in django/conf/locale
Note:
See TracTickets
for help on using tickets.
That's not broken, that's per design. The translation finding code uses the available global translations as a guideline. It checks against the LANGUAGES setting, which must be a subset (or equal to) the list of available languages. If you want to add a new language, either provide a global translation (as many strings in your application will come from the django core source, that's a good idea anyway - validators, tags, date formats and many other parts in django core will "leak" english texts into your project without doing that) or just copy over the 'en' language files to your new language.
Of course, if you add a translation for your language, it would be nice to attach that to a new ticket, so that we can incorporate it into the django core source :-)
Wether or not that guard check should be removed or should stay is something that's best first discussed in the django-i18n list. The problem is, without a global translation for your language, there will be english texts in your site, which you won't see show up as translation strings in your project, as the sources are in the django core.