Opened 19 years ago

Closed 19 years ago

Last modified 18 years ago

#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

Change History (1)

comment:1 by hugo, 19 years ago

Resolution: invalid
Status: newclosed

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.

Note: See TracTickets for help on using tickets.
Back to Top