> Betreff: Re: [Zope-dev] Re: New i18n locale extraction concept
> >> The best option whould be to split zope.app.locales into usefull
> >> packages. The not so good optipon whould be to copy over
> the relevant
> >> classes and scripts to the recipe and skip the dependency to
> >> zope.app.locale.
> >> I also started to use the recipe in z3c.locales and
> zam.locales. Take
> >> a look at this package for a real usecase.
> >> What do you think? Should we switch the locale extraction to that
> >> concept for the zope.* packages too or not?
> > Exctaction should be in a recipe, of course. But I'm also
> > for having the translations in the package and having one
> domain per
> > package. `
> One drawback of this, is that it will be a pain for
> translators to gather and update translations, unless a tool
> is provided. Currently with only one file, there is already
> few languages. It's much more efficient for translators to
> work on one single big file than a lot of small ones.
+1, that's the main reason why I preferre shared domains
in packages. Sometimes I only have one or two message ids
which I think should stay in a shared domain.pot file rather
then add a new domainn for them.
Of corse a large amount of message ids in a z3c.* package
can still provide a own domain. That's allways a valid option.
My main point of view is the translator which have to speak
a language. In his point of view it's simpler to have a single
file instead of handling all the different packages he probaly
doesn't even use.
> It will also prevent from using one same translation at
> different places, and identical messages will have to be
> translated several times, with the risk of not being
> consistent across packages. Unless everything is done by one
> person, using a translation memory.
+1, very good ideas!
> It seems obvious and logical to split the translation
> domains, but we need to provide a tool such as
> that will allow
> - the package developer to submit a new POT file (by mail,
> upload, or anything)
> - translators to quickly see what need to be done and submit
> updated POs
I agree, a tool whould be great. But the first we need to
offer i18n extract script which can handle our new egg
based buildout process. z3c.recipe.i18n is the only one
which could handle this right now.
> Ideally, the recipe i18n tool should be able to extract,
> merge, and give stats, just like in the monolithic zope release.
Yes, z3c.recipe.i18n does this right now. The -d option uses
one or more egg or develop externals as argument instead of
one single path.
> Zope-Dev maillist - Zope-Dev@zope.org
> ** No cross posts or HTML encoding! ** (Related lists -
> http://mail.zope.org/mailman/listinfo/zope )
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -