Django

Code

Ticket #1215 (closed: invalid)

Opened 3 years ago

Last modified 2 years ago

Locale finding is broken.

Reported by: jiivan Assigned to: hugo
Milestone: Component: Internationalization
Version: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: 0 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

Attachments

Change History

01/13/06 08:36:00 changed by hugo

  • status changed from new to closed.
  • resolution set to invalid.

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.


Add/Change #1215 (Locale finding is broken.)




Change Properties
Action