Opened 14 years ago

Closed 14 years ago

Last modified 14 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

Description

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.

Regards

Change History (11)

comment:1 by Jannis Leidel, 14 years ago

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 by dauerbaustelle, 14 years ago

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 by dauerbaustelle, 14 years ago

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 by Jannis Leidel, 14 years ago

Resolution: worksforme
Status: reopenedclosed

Please don't re-open tickets.

The settings.py 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 by dauerbaustelle, 14 years ago

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 by Jannis Leidel, 14 years ago

I see, you are probably using ./manage.py shell for testing which enforces English to prevent problems with translations during running a management command: http://code.djangoproject.com/browser/django/trunk/django/core/management/base.py?rev=11483#L206

comment:7 by dauerbaustelle, 14 years ago

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

comment:8 by Jannis Leidel, 14 years ago

Yes, don't use manage.py 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 by dauerbaustelle, 14 years ago

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 by Alex Gaynor, 14 years ago

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 by dauerbaustelle, 14 years ago

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