atom feed1 message in net.sourceforge.lists.plone-i18n[Plone-i18n] locales and default lang...
FromSent OnAttachments
Maurits van ReesSep 4, 2008 2:26 pm 
Subject:[Plone-i18n] locales and default language that is not English
From:Maurits van Rees (m.va@zestsoftware.nl)
Date:Sep 4, 2008 2:26:14 pm
List:net.sourceforge.lists.plone-i18n

Hi,

I came across some unexpected behaviour where zope.i18n was translating a bit too enthusiastically, even when no translations were actually wanted.

The situation

-------------

I have a package xm.theme. The templates and python files are all in English of course. It has locales for Dutch.

I am using that package on a Plone 3.1 site. That site has Dutch as default language and English as a second allowed language. No LinguaPlone. portal_languages is set to take the browser language preference into account.

I visit the site with a browser that only wants Dutch. The complete UI is shown in Dutch. So translations are working fine in that case.

I then visit the site with a browser that only wants English. Now most of the site UI is in English. But the msgids in the xm.theme domain remain shown in Dutch.

The problem

-----------

The problem here is that the xm.theme translationdomain from zope.i18n only has a catalog for the Dutch language (and some test catalog). The language negotiator (the code that decides what the target language will be) gets ['en', 'nl, 'en'] as list from IUserPreferredLanguages. Since there is no English catalog for xm.theme, Dutch is chosen as target language.

This probably makes sense. The msgids from xm.theme might have been written in Chinese instead of English. The translation domain has no way of knowing that. So it returns Dutch as that is the site default (which makes it ends up in the IUserPreferredLanguages).

The workaround

--------------

I solved it by copying the pot file into a new locales/en/LC_MESSAGES folder. I left the msgstrs empty. One Zope restart later and I got my English translations, exactly like I wanted them.

Note that for old-style (but still kicking) translations in the i18n dir (so handled by PlacelessTranslationService) this problem does not appear.

Solutions ?

-----------

So: is this the right way to do it? Should every package with locales explicitly create an 'en' locale (simply a copy of the pot file) to avoid situations like these?

Are there ways to signal that English (or Chinese or whatever) is the language used by the templates/python? For example, the pot file itself clearly states its language to be English; but this is not picked up.

BTW, without having tried it, I would now expect that - without the locales/en/ directory - a site with German as default language and English as user preferred (and allowed) language would get the English words: there is no match between the preferred languages ('de' and 'en') and the available languages ('nl') so no translation is done.

Cheers,