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.: p i18n:translate=bank-financialBank/p 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: p i18n:translate=Please go to the bank and get some money/p 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
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
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
