#24413 closed Bug (fixed)
Translations for language "en" missing
Reported by: | Tomasz Kontusz | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 1.8alpha1 |
Severity: | Release blocker | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
It seems translations for "en" are missing, which gives wrong results for LANGUAGE_CODE != 'en'.
I have LANGUAGE_CODE = 'pl', use the i18n/setlang/ view to set my current language to 'en', and visit a login page based on django.contrib.auth.forms.AuthenticationForm. Field labels are still in polish, but the strings the I've explicitly translated are in english. I expected the labels to use english versions, but looking here https://github.com/django/django/blob/master/django/contrib/auth/locale/en/LC_MESSAGES/django.po it looks like none of those are actually provided (so Django falls back to LANGUAGE_CODE).
Change History (7)
comment:1 by , 10 years ago
Severity: | Normal → Release blocker |
---|---|
Triage Stage: | Unreviewed → Accepted |
comment:2 by , 10 years ago
For reference, here's what I did to reproduce the issue:
1) Start a new project with djangoadmin startproject myproject
2) Change LANGUAGE_CODE = 'pl'
in myproject/settings.py
3) Edit myproject/urls.py
to contain the following:
from django.conf.urls import url from django.http import HttpResponse from django.utils import translation def index(request): translation.activate('en') return HttpResponse(translation.ugettext('username')) urlpatterns = [ url(r'^$', index), ]
4) Start runserver
and navigate to the root URL
When doing that, you'll see that the string 'username'
remains translated to Polish (I believe that's the issue being reported here)
You'll note that using translation.activate('en-us')
in the view makes the correct translation appear again.
comment:3 by , 10 years ago
Has patch: | set |
---|
comment:4 by , 10 years ago
Component: | Uncategorized → Internationalization |
---|
comment:5 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:6 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Hi,
I think I can reproduce this locally but I haven't managed to build a failing test case yet.
Doing some manual bisecting, it seems that a5f6cbce07b5f3ab48d931e3fd1883c757fb9b45 introduced the regression.
I'm bumping to "Release blocker" since it's a regression from 1.7.
Thanks!