Hi Fran, Sorry if I can't help but I've been looking myself for a possibly quick answer to a strange problem regarding i18n. I am running latest svn rev and the strangest thing is that in the admin app I am presented with both LANGUAGES and LANGUAGE_CODE. My custom templates however do not recognize these variables, even though they're being passed through the same middleware and context processors (or at least I'd like to believe that) Maybe i'm just thinking out loud, Regards RiCardo
On Aug 28, 1:44 am, "Fran O'Reilly" <[EMAIL PROTECTED]> wrote: > I've raised the following ticket for this issue: > > http://code.djangoproject.com/ticket/8626 > > Have also confirmed on latest from svn, 1.0-beta_2-SVN-8643. The > ticket includes all the files needed to reproduce the problem. > > On Aug 27, 5:35 pm, "Fran O'Reilly" <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > I've got a situation where even though the user has selected language > > "en", the "en_US" translations are being rendered. My setup has three > > languages - "en", "en-us" and "en-gb". I also have three locale > > translations corresponding, i.e. "en", "en_GB" and "en_US". > > > Anyone seen a similar problem before? > > > My settings file has the following: > > > LANGUAGE_CODE = 'en' > > > ugettext = lambda s: s > > LANGUAGES = ( > > ('en', ugettext('English (Default)')), > > ('en-us', ugettext('English (American)')), > > ('en-gb', ugettext('English (British)')), > > ) > > > I have created translations for each of the three locales above using > > the normal django-admin.py commands: > > > % django-admin.py makemessages -l en > > % django-admin.py makemessages -l en-gb > > % django-admin.py makemessages -l en-us > > > ... then filled in the django.po files with the translations (for this > > test, I made sure to use text that was different for each locale so I > > could tell which translations were coming through), then : > > > % django-admin.py compilemessages > > > then restart my server to pick them up. > > > I also have locale middleware setup so that LANGUAGE_CODE is available > > on the request. Here's my settings.py: > > > MIDDLEWARE_CLASSES = ( > > 'django.middleware.common.CommonMiddleware', > > 'django.contrib.sessions.middleware.SessionMiddleware', > > 'django.middleware.locale.LocaleMiddleware', > > 'django.contrib.auth.middleware.AuthenticationMiddleware', > > 'django.middleware.doc.XViewMiddleware', > > 'django.middleware.transaction.TransactionMiddleware', > > ) > > > Here's a snippet from my template. It lives at /index.html/ and has a > > dropdown control that allows the user to select the default language. > > It's basically just a homepage where the user chooses their preferred > > language setting with a dropdown form and submit button. It hooks into > > the django set-language view (django.conf.urls.i18n) being mapped to > > the url /i18n/setlang/. It has a h1 element that is translated as well > > as a debug print of the value of request.LANGUAGE_CODE. The "Homepage" > > text is translated in each of the locale's django.po files with text > > like "Homepage (en)", "Homepage (en-gb)" or "Homepage (en-us)" so I > > can tell which translation is coming through to the template. > > > --snip-- > > <form action="/i18n/setlang/" method="post"> > > <input name="next" type="hidden" value="/index.html" /> > > <label for="lang">{% trans "Current selected native language/dialect" > > %}</label> > > <select id="lang" name="language"> > > {% for lang in LANGUAGES %} > > <option value="{{ lang.0 }}" {% ifequal lang.0 request.LANGUAGE_CODE > > %}selected {% endifequal %}>{{ lang.1 }}</option> > > {% endfor %} > > </select> > > <input type="submit" value="Change" /> > > </form> > > > <p>LANGUAGE_CODE={{ request.LANGUAGE_CODE }}</p> > > > <h1>{% trans "Homepage" %}</h1> > > --snip-- > > > So when I select the language "en", the template renders the "en_US" > > values in the template which is wrong - expect "en" locale. If I > > switch to "en-gb" or "en-us", it works as you'd expect, pulling back > > the en_GB or en_US locale translations. Just with "en", for some > > reason, it pulls back the "en_US" translations, but obviously I'd > > expect the "en" translation to come back. > > > Also very odd: If I take out the "en_US" locale and language code from > > the above, the "en" and "en_GB" locales now work correctly! It's as if > > there were something special about the "en_US" locale in the code > > somewhere?! > > > I'm running django svn 8015, about a month old or thereabouts. Haven't > > had time to try this on the latest svn. > > > Any help appreciated, > > > Fran O'Reilly. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
