Philipp von Weitershausen wrote:
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)
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.:
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.
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
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.
Zope3-dev mailing list