Hi Christophe
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 advocating 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 http://translationproject.org/extra/matrix.html 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.
Christophe
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )