Roger Ineichen, on 2008-05-07:
> Uhaaa, that's a left over from a copied README.txt file.
> I need to review that part again.
I thought it might be something like that. :-)
>> Why specify both eggs and packages? And why specify those
>> packages in the setup.py too? At least that is what I see in
> Eggs are needed for setup your project, or probably a working
> setup like in any other package.
> Packages are used for extract locales from. That could be very
> different then the egg setup. The i18nextrac.py will only deep
> into this packages, but probably this packages will need different
> eggs which they import from.
I would hope that it is possible to just list the eggs that you are
interested in, have buildout install all their requirements (as listed
in their setup.py) and have the recipe only extract message ids from
those original eggs without their dependencies. Then the 'packages'
directive would not be necessary anymore.
Or perhaps when the packages option is empty, it takes the value of
the eggs option as default.
I do not know if this is possible and I have not gone in with a pdb to
> Note, if you run the i18nextract script, all module must be
> there like in a running application. You can't only use
> the files which will contain locales. Also modules which
> this packages import from must be there.
That should not be necessary I think. At least I am not used to it.
When I use i18ndude for making pot/po files for a Plone
product/package and I have "from Products.CMFPlone import something"
in a file, then this import does not really take place. I expect in
the case of python files it simply looks for lines like:
_(u"My message to the world.")
> This isn't aproblem since the zope.app.locales dependes on
> everyting which we developed the last years. Because
> zope.app.locales depends on almost everything.
Do you envision using this recipe also for translating a single
package? Or is your target really only big software collections like
zope.app.*? I wonder a bit if it makes the second use case possible
by making the first use case harder.
It worked fine when I tried it on zam.locales btw, except that all
lines in the resulting .pot file were changed, but that is because of
Windows versus Unix line endings in subversion, which has nothing to
do with this recipe.
> I see, I 'll add a normalizer for that. I thought it was already
> there, but could be not correct implemented.
If you have a fix for that and you need me to test that on Linux, let
Cheers and thanks,
Maurits van Rees | http://maurits.vanrees.org/
Work | http://zestsoftware.nl/
"This is your day, don't let them take it away." [Barlow Girl]
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -