Dieter Maurer wrote:
Jean-Marc Orliaguet wrote at 2006-5-30 22:13 +0200:
...
Dieter Maurer wrote:
...
In my view the translation domain is vital for translators --
as the domain guides the correct translations.
...
But it is the application that eventually sets the domain name
Jean-Marc Orliaguet wrote at 2006-5-30 22:13 +0200:
...
Dieter Maurer wrote:
...
In my view the translation domain is vital for translators --
as the domain guides the correct translations.
...
But it is the application that eventually sets the domain name to use,
based on the context.
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
Jean-Marc Orliaguet wrote:
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
On Tuesday 30 May 2006 05:25, Jean-Marc Orliaguet wrote:
what is the solution? add an option in i18n:registerTranslations? such as:
i18n:registerTranslations directory=locales domain=mydomain /
and let the ZCML handler update existing catalogs?
There is no solution right now. I have come
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
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
