[Zope3-dev] Re: selecting the translation domain in ZCML

[Hanno Schlichting]

Wichert Akkerman wrote:
> Previously Jean-Marc Orliaguet wrote:
>> this is OK for most use cases because packages manage their own domain, 
>> but there is a case which I don't know how to solve, i.e.  when a 
>> package is supposed to register translations into another package's 
>> translation domain?.
> 
> A po file includes its domain in its header; I'm assuming zope is smart
> enough to extract and use that. If not - please fix that :)

This is one of the non-standard headers Zope2 (probably
PlacelessTranslationService) invented to use if the also non-standard
i18n folder layout is used for translation files.

The standard way as implemented in Zope3 is to get the translation
domain from the filename itself.

I would have thought, that by registering translations via:

<i18n:registerTranslations directory="locales" />

all of the files would be found in there. For example this could look like:

locales/LC_MESSAGES/de/mydomain.mo
locales/LC_MESSAGES/fr/mydomain.mo
locales/LC_MESSAGES/de/myseconddomain.mo
locales/LC_MESSAGES/pt_BR/myseconddomain.mo

All these files are uniquely identified and should be registered without
any problem.

A problem arises only when there is already a utility registered for
that particular domain.

I think there are different use-cases that we need to consider here:

1. A package author just doesn't like the translation files provided by
the original package for some reason.

This could be solved by using i18n:registerTranslations in an
overrides.zcml which should replace all existing translation domain
utilities.

2. A site administrator wants to change only some of the messages of a
translation domain, as they might conflict with a company policy or are
inappropriate for the audience of a specific site.

This is a use-case often requested in the Plone world and which
PlacelessTranslationService currently solves by yet another evil hack
providing a global folder in the instance home of a zope site, whose
translation files are queried before all other translation files. But
these fall back to all the normally registered translation files.

I think this use-case in Zope3 is better solved by creating local
translation domain utilities which act in the same way of a
semi-transparent proxy of existing translation domains. That is if a
message is not found in the local utility it should fall back to the
global one. For translation domains it makes sense to do this on the
message level and not only the domain (utility) level.

3. A package author wants to change only some messages of an existing
package.

Actually I have no good idea how this could be solved and if this is
even a legitimate use-case that Zope should support in the core.
Arguments and examples would be welcome  :)

I should probably note that while I didn't found the time yet to write a
mail to this list about my plans, I'm currently working on a Google
Summer of Code project for the Plone Foundation whose goal it is to port
all existing i18n/l10n infrastructure used in the Plone world to Zope3
technologies.

My current plan is to get some of these, which aren't CMS specific, into
Zope core. So if nobody has time to work on the use-cases mentioned in
this mail I might end up having time for them  ;)

Cheers,
Hanno