Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#12131 closed (invalid)

Translation not recognized when not using requests

Reported by: dauerbaustelle Owned by: nobody
Component: Translations Version: 1.1
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Hi there,

I'm currently using django's ORM and translation library for a project. I'm using ugettext for marking strings as translatable and LANGUAGE_CODE is correctly set ("de-DE" in my case). However, django does not correctly recognize the language, django.utils.translation.get_language() always returns the default "en-us". If I set the language manually via activate(...), get_language returns that language code but the actual translation seems to have happened before so there's no way to get the translated strings.

By the way, using django's admin interface the right language is used. I have added the LocalizationMiddleware to the list of active middlewares. Don't hesitate to go through the code linked above.


Change History (11)

comment:1 Changed 9 years ago by Jannis Leidel

Resolution: worksforme
Status: newclosed

You probably want to use django.utils.translation.ugettext_lazy instead of ugettext to translate strings dynamically dependending on the request/response cycle (e.g. with the LocaleMiddleware).

comment:2 Changed 9 years ago by dauerbaustelle

Dammit, yes. Humm, I thought it would be lazy translation by default, documentation should be more clear here.
Also this

Application message files are a bit complicated to discover -- they need the LocaleMiddleware. If you don't use the middleware, only the Django message files and project message files will be processed.

paragraph should be highlighted.

comment:3 Changed 9 years ago by dauerbaustelle

Resolution: worksforme
Status: closedreopened

Or, wait - I don't have any requests, you know. The language is hardcoded in the settings file, so I shouldn't need the lazy thing for that, should I?

comment:4 Changed 9 years ago by Jannis Leidel

Resolution: worksforme
Status: reopenedclosed

Please don't re-open tickets.

The file of your project contains LANGUAGE_CODE = 'en-us' which will be used by ugettext to translate strings. That's also why django.utils.translation.get_language() will return 'en-us' by default.

comment:5 Changed 9 years ago by dauerbaustelle

I've previously said that my LANGUAGE_CODE is set to "de-DE". In the code you've seen it's "en-us" because that's django's default setting and I didn't touch it - but I changed it in my local clone ;-)

comment:6 Changed 9 years ago by Jannis Leidel

I see, you are probably using ./ shell for testing which enforces English to prevent problems with translations during running a management command:

comment:7 Changed 9 years ago by dauerbaustelle

Is there a way to use translations in the interpreter shell anyways?

comment:8 Changed 9 years ago by Jannis Leidel

Yes, don't use shell but set the environment variable DJANGO_SETTINGS_MODULE to the Python path of your settings module and use the interactive Python interpreter directly.

comment:9 Changed 9 years ago by dauerbaustelle

Resolution: worksforme
Status: closedreopened

What I don't get: If I use *_lazy, the translations work, but if I use the non-lazy versions of translation functions they don't work. Non-lazy translation takes place immediately when the function is called and the resulting language strings depend (i.a.) on the LANGUAGE_CODE setting, is this right? Then I wonder why the lazy stuff works but the non-lazy doesn't.

comment:10 Changed 9 years ago by Alex Gaynor

Resolution: invalid
Status: reopenedclosed

Please stop reopening this ticket, trac is not the place for user support, please use the django-users mailing list or #django to ask these questions.

comment:11 Changed 9 years ago by dauerbaustelle

I'm sorry, I didn't want to reopen it. I think it's a bug, though...

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