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 _______________________________________________ Zope3-dev mailing list [email protected] Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
