Re: [Zope3-dev] Re: selecting the translation domain in ZCML
Stephan Richter wrote:
> On Thursday 01 June 2006 04:07, Philipp von Weitershausen wrote:
>> That's not how we typically use translation domains, though. In most
>> projects, one translation domain denotes all the translations of a
>> particular piece of software (a library, an application, etc.). So Zope
>> use 'zope', Plone uses 'plone', etc.
>
> I have come to the conclusion that this is a major mistake. ;-) And I am the
> culprit too! :-( I think each package should have its translation domain.
That case is included in the above ("piece of software" can be a
package, too...).
> This makes it much easier to override translation domains and provide custom
> translations, which is something I wanted really bad for formlib in the last
> project.
Both approaches have their advantanges, as we discussed some time ago. I
think we should think about the possibility of making Zope 3 a bit more
modular for Zope 3.4. This wouldn't only include i18n domains for each
project but perhaps also individual changelogs and such. Since we didn't
get Zope 3.3 to ship primarily as eggs, I would hope that we'll make it
for Zope 3.4, hence it would make sense to split certain things up.
Someone should write a proposal *wink*.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: selecting the translation domain in ZCML
On Thursday 01 June 2006 04:07, Philipp von Weitershausen wrote: > That's not how we typically use translation domains, though. In most > projects, one translation domain denotes all the translations of a > particular piece of software (a library, an application, etc.). So Zope > use 'zope', Plone uses 'plone', etc. I have come to the conclusion that this is a major mistake. ;-) And I am the culprit too! :-( I think each package should have its translation domain. This makes it much easier to override translation domains and provide custom translations, which is something I wanted really bad for formlib in the last project. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: selecting the translation domain in ZCML
Philipp von Weitershausen wrote: Dieter Maurer wrote: Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200: ... although -- while thinking about it, putting the domain name in .po files breaks the separation on concerns between translators and application developer. Translators shouldn't have to worry about translation domains. That's application specific. Are you sure? In my view the translation domain is vital for translators -- as the domain guides the correct translations. For example, in German we have the word "Bank". It may mean "bench" or "bank", depending on the translation domain. That's not how we typically use translation domains, though. In most projects, one translation domain denotes all the translations of a particular piece of software (a library, an application, etc.). So Zope use 'zope', Plone uses 'plone', etc. In order to avoid ambiguities like the one you mentioned, it is recommended to use explicit message ids whereever short labels occur, e.g.: Bank Then 'bank-financial' is the message id for this message. In longer sentences, this often isn't necessary because ambiguities will be resolved by the context: Please go to the bank and get some money Of course, your example is a bit backwards because the ambiguity isn't in English (which typically is the source language), but in German. In most cases, the ambiguities come from English, though, for example because verbs and nouns are spelt the same way. Philipp yes that's the use case I have (1 domain = 1 application/package). I'm using dotted names to create namespaces or "subdomains" inside a same domain (e.g. cpsskins.widget.dropdownMenu) the actual need right now is to be able to merge translations , i.e. for a package to be able add translations into another domain or to override an other package's translations. That's two use cases that can be merged into one. there might be an issue with ZCML configuration stages. It should be made possible in ZCML to specify the order in which domains are loaded or merged, a bit like with UNIX rc scripts. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: selecting the translation domain in ZCML
Dieter Maurer wrote: > Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200: >> ... >> although -- while thinking about it, putting the domain name in .po >> files breaks the separation on concerns between translators and >> application developer. Translators shouldn't have to worry about >> translation domains. That's application specific. > > Are you sure? In my view the translation domain is vital for translators -- > as the domain guides the correct translations. > > For example, in German we have the word "Bank". > It may mean "bench" or "bank", depending on the translation domain. That's not how we typically use translation domains, though. In most projects, one translation domain denotes all the translations of a particular piece of software (a library, an application, etc.). So Zope use 'zope', Plone uses 'plone', etc. In order to avoid ambiguities like the one you mentioned, it is recommended to use explicit message ids whereever short labels occur, e.g.: Bank Then 'bank-financial' is the message id for this message. In longer sentences, this often isn't necessary because ambiguities will be resolved by the context: Please go to the bank and get some money Of course, your example is a bit backwards because the ambiguity isn't in English (which typically is the source language), but in German. In most cases, the ambiguities come from English, though, for example because verbs and nouns are spelt the same way. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: selecting the translation domain in ZCML
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: 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 Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: selecting the translation domain in ZCML
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: 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 Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
