[Grok-dev] Re: i18nextract

[Philipp von Weitershausen]

Uli Fouquet wrote:
>>>> The i18nextract script actually just calls a stuff in 
>>>> zope.app.locales.extract. This could be wrapped in a fucntion and 
>>>> exposed by an entry point in zope.app.locales.
>>> There's a recipe by lovely around to integrate it with buildouts.
>> Does someone want to volunteer and dig up this recipe? It might be nice 
>> to do this by default for grokproject.
> 
> The lovely-recipe is really easy going (well, lovely ;-). I modified
> grokproject, so that buildout of a new generated project now
> automatically creates i18nextract and friends in the bin-directory.

Uli, thanks for taking the initiative. I do appreciate it, so please 
don't get me wrong when I sound negatively below, but I think you shot a 
bit too quickly on this one. As Jim says, speed kills.


First of all, I didn't know the lovely i18n recipe existed. I think it's 
the wrong approach. More specifically, I don't think that a dedicated 
recipe just to get scripts (that in end just make calls to stuff in 
other packages) into 'bin' is the way to go. setuptools has the entry 
point system for this. I prefer using as much of the standard setuptools 
stuff as possible.

I said this in an earlier post in this thread. I wish my suggestion 
would at least have been considered. I have now modified 
zope.app.locales to expose i18nextract as an entry point. I have 
modified the buildout.cfg in its SVN project dir to show how to do a 
deployment of that script in a manner similar to what the lovely i18n 
recipe offers.

> The i18n-tools are customizable using buildout.cfg. See the [i18n]
> section in buildout.cfg. It is quite self-explanatory.

I disagree. You just copied the example section from README.txt, which 
is a rather poor document, really. It doesn't document anything. It's 
just a test.

I, for one, was a bit puzzled by this 'z3c.csvvocabulary.csvStrings' 
thing. My educated guess is that it allows you to read i18n messages 
from CSV files. It introduces an unnecessary dependency, though.

Also, you made z3c.csvvocabulary a dependency of the template egg in 
setup.py_tmpl. This is quite wrong. The template project has NO 
dependency on this whatsoever. It's just the buildout deployment that 
happens to use it. So this should never have gone into setup.py_tmpl but 
into buildout.cfg_tmpl.

Again, speed kills. It usually pays off taking the time to think about 
where things really should go.

I've ripped out the two references to z3c.csvvocabulary.

> I also put zope.i18nmessageid into the dependency list of the created
> projects, which is a pure convenience feature, that might be handy if
> using i18n with a grokproject.

I reverted this. Nothing in the template egg currently depends on 
zope.i18nmessageid. I find it confusing to introduce this dependency 
"just for the heck of it". If we want to provide convenience, then lets 
go all the way and add a boilerplate MessageFactory to the code 
somewhere. Then that dependency would be justified.


Last but not least, we now enable Grok developers to dump a POT file 
into src/<pkg>/locales. I think that this directory should therefore be 
created by default and not magically appear when you run bin/i18nextract 
for the first time.

Moreover, configure.zcml should automatically load the translations from 
the 'locales' directory via <i18n:registerTranslations ... />. And then 
we probably do want that MessageFactory in the code by default so that 
people can take advantage of it. etc. etc.

We'll end up with lots of boilerplate.


I don't think we've thought this through. Unless people object, I will 
rip out the whole i18nextract story again from grokproject (it hasn't 
been released anyway yet) until we come up with a sensible way of 
dealing this. Right now there are just too many unanswered questions:

* recipe vs. entry point in zope.app.locales?

* how much and which i18n boilerplate do we want in an empty
   grokproject?


-- 
http://worldcookery.com -- Professional Zope documentation and training