Code

Opened 5 years ago

Closed 5 years ago

Last modified 5 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: UI/UX:

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

Attachments (0)

Change History (11)

comment:1 Changed 5 years ago by jezdez

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to worksforme
  • Status changed from new to closed

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

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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 5 years ago by jezdez

  • Resolution set to worksforme
  • Status changed from reopened to closed

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 Changed 5 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 5 years ago by jezdez

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 Changed 5 years ago by dauerbaustelle

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

comment:8 Changed 5 years ago by jezdez

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 Changed 5 years ago by dauerbaustelle

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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 5 years ago by Alex

  • Resolution set to invalid
  • Status changed from reopened to closed

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

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.