[Grok-dev] Re: i18nextract
Philipp von Weitershausen
philipp at weitershausen.de
Wed Sep 12 18:00:57 EDT 2007
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
> 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
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
http://worldcookery.com -- Professional Zope documentation and training
More information about the Grok-dev