Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: 5. writing makers - Proposal: Pass in the additional arguments and fall back >> to the old signature for BBB. >> Done. I also added site_zcml as argument. >> >> What about wrapping py_strings, zcml_strings and tal_strings >> in functions that implement the new interface? This would >> make it possible to add them to the makers list and call them >> in the same loop. > > Yes, why not. Probably we should do this together with a > refactoring and change/enhance the method signature for > the pot makers. I'm not sure I understand what you mean. What exactly do you want to change/enhance? This checkin already changed/enhanced the way pot makers are called: http://svn.zope.org/?rev=101958&view=rev Do you want to improve that further or do you propose to modify py_strings, zcml_strings and tal_strings? They all have currently different signatures. I can't see a way to unify that in a backwards compatible way. That's why I proposed to wrap them in new z3c.recipe.i18n specific functions. I propose I start with the changes I have in mind. Of course you can improve that further after I'm done. Cheers, Yuppie ___ 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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie > Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract > > Hi Roger! > > > >> 1.) running tests > >> - > >> > >> Proposal: Remove those two lines in test.py. > > Done. > > >> 2.) looking up the product version > >> -- > >> > >> Proposal: Catch the error. Return an empty string if > version is not > >> found. > > The problem was somewhere different: Caused by wrong > dependencies zope.app.applicationcontrol was not available. > After fixing the dependencies the method works without error > and 'Development/Unknown' is returned with Zope 2. That's > sufficient for me. > > >> 3.) customizing the .pot header > >> --- > >> > >> Proposal: The easiest and most flexible way to customize > this seems > >> to be an option that allows to specify a file that contains the > >> pot_header template. > > This is still missing. I plan to subclass POTMaker in > z3c.recipe.i18n instead of modifying zope.app.locales.extract. > > >> 4.) looking up basePath > >> --- > >> > >> Proposal: Use the 'if' code for all packages. > > Done. (At least if nobody complains.) > > >> 5. writing makers > >> - > >> > >> Proposal: Pass in the additional arguments and fall back > to the old > >> signature for BBB. > > Done. I also added site_zcml as argument. > > What about wrapping py_strings, zcml_strings and tal_strings > in functions that implement the new interface? This would > make it possible to add them to the makers list and call them > in the same loop. Yes, why not. Probably we should do this together with a refactoring and change/enhance the method signature for the pot makers. Regards Roger Ineichen _ END OF MESSAGE ___ 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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger! >> 1.) running tests >> - >> >> Proposal: Remove those two lines in test.py. Done. >> 2.) looking up the product version >> -- >> >> Proposal: Catch the error. Return an empty string if version >> is not found. The problem was somewhere different: Caused by wrong dependencies zope.app.applicationcontrol was not available. After fixing the dependencies the method works without error and 'Development/Unknown' is returned with Zope 2. That's sufficient for me. >> 3.) customizing the .pot header >> --- >> >> Proposal: The easiest and most flexible way to customize this >> seems to be an option that allows to specify a file that >> contains the pot_header template. This is still missing. I plan to subclass POTMaker in z3c.recipe.i18n instead of modifying zope.app.locales.extract. >> 4.) looking up basePath >> --- >> >> Proposal: Use the 'if' code for all packages. Done. (At least if nobody complains.) >> 5. writing makers >> - >> >> Proposal: Pass in the additional arguments and fall back to >> the old signature for BBB. Done. I also added site_zcml as argument. What about wrapping py_strings, zcml_strings and tal_strings in functions that implement the new interface? This would make it possible to add them to the makers list and call them in the same loop. Cheers, Yuppie ___ 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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Roger Ineichen wrote: >> What about testing it like this: >> >> We remove the 'else' part and wait until someone complains. >> In that case we have a scenario for testing and fixing the >> issue. If nobody complains, the 'else' part was indeed useless. >> >> The current code doesn't work for me because 'src' is found >> but not the right place to split the path. > > I'm fine with that. I can test the changes with the project > which I used as base when I wrote the path cleanup code. I checked in that change. Can you please test? Thanks! Yuppie ___ 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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Yuppie
> Betreff: Re: z3c.recipe.i18n and zope.app.locales.extract
>
> Hi Roger,
>
>
> Thanks for your feedback!
>
> Roger Ineichen wrote:
> >> -Ursprüngliche Nachricht-
> >> 2.) looking up the product version
> >> --
> >>
> >> POTMaker._getProductVersion() doesn't work for me.
> >> zope.app.applicationcontrol is not used by Zope 2 and is
> not part of
> >> the specified dependencies. This raises an error.
> >>
> >> Proposal: Catch the error. Return an empty string if
> version is not
> >> found.
> >
> > Sounds good to me as a workarround
> >
> > Probably we should try to use the package version of the egg which
> > uses the i18n recipe?
>
> Not every buildout is itself an egg. So in any case we need a
> fallback.
>
> In my use case I plan to set the version manually in the
> pot_header template. So I don't need the version lookup.
Agreed, sound good to me.
> i18nextract.main() initializes POTMaker this way:
>
> # setup pot maker
> maker = POTMaker(output_file, '')
>
> The second argument is the path that is used by
> POTMaker._getProductVersion() to look up a 'version.txt'
> file. Maybe we could use a better path than ''. But I'll
> leave it to someone else to figure that out.
I'm not sure and didn't look at the code but I guess
the existing zope implementation depends on subversion
get version info or something like that. This pattern is
probably totaly out of date since we use buildout and eggs.
> >> 4.) looking up basePath
> >> ---
> >>
> >> i18nextract.main() contains these lines:
> >>
> >> # add maker for each given path
> >> for pkgName, path in eggPaths:
> >> srcIdx = path.rfind('src')
> >> if srcIdx == -1:
> >> # this is an egg package, strip down base path
> >> basePath = path
> >> moduleNames = pkgName.split('.')
> >> moduleNames.reverse()
> >> for mName in moduleNames:
> >> mIdx = path.rfind(mName)
> >> basePath = basePath[:mIdx]
> >> pkgPath = path[len(basePath):]
> >> else:
> >> # this is a package linked in as externals
> >> basePath = path[:srcIdx]
> >> pkgPath = path[len(basePath):]
> >>
> >> I don't understand why we need different code for
> "packages linked in
> >> as externals". The "egg package" code works actually better for
> >> linked in packages that don't follow the 'src' convention.
> >>
> >> Proposal: Use the 'if' code for all packages.
> >
> > I was fighting several times with this part during coding.
> > The only thing which this part has to make sure is that we
> do not use
> > anything outside of the package in our path.
> >
> > The reason for not including everything outside the package in our
> > path is that such a path whould be depend on the local setup e.g.
> >
> > D:\foo\dev\zope\session:3
> >
> > We only have to make sure that this never will happen and
> that we for
> > each use case generate path like:
> >
> > zope/session.py:3
> >
> > It could be that the if part is working for all usecases.
> > but I'n not sure without debugging.
>
> Debugging doesn't help much if we don't know all use cases.
Yes, that's true
> What about testing it like this:
>
> We remove the 'else' part and wait until someone complains.
> In that case we have a scenario for testing and fixing the
> issue. If nobody complains, the 'else' part was indeed useless.
>
> The current code doesn't work for me because 'src' is found
> but not the right place to split the path.
I'm fine with that. I can test the changes with the project
which I used as base when I wrote the path cleanup code.
Agreed, using "src" as a hard coded name can end in a bad
result.
Regards
Roger Ineichen
___
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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi Roger,
Thanks for your feedback!
Roger Ineichen wrote:
>> -Ursprüngliche Nachricht-
>> 2.) looking up the product version
>> --
>>
>> POTMaker._getProductVersion() doesn't work for me.
>> zope.app.applicationcontrol is not used by Zope 2 and is not
>> part of the specified dependencies. This raises an error.
>>
>> Proposal: Catch the error. Return an empty string if version
>> is not found.
>
> Sounds good to me as a workarround
>
> Probably we should try to use the package version of the egg
> which uses the i18n recipe?
Not every buildout is itself an egg. So in any case we need a fallback.
In my use case I plan to set the version manually in the pot_header
template. So I don't need the version lookup.
i18nextract.main() initializes POTMaker this way:
# setup pot maker
maker = POTMaker(output_file, '')
The second argument is the path that is used by
POTMaker._getProductVersion() to look up a 'version.txt' file. Maybe we
could use a better path than ''. But I'll leave it to someone else to
figure that out.
>> 4.) looking up basePath
>> ---
>>
>> i18nextract.main() contains these lines:
>>
>> # add maker for each given path
>> for pkgName, path in eggPaths:
>> srcIdx = path.rfind('src')
>> if srcIdx == -1:
>> # this is an egg package, strip down base path
>> basePath = path
>> moduleNames = pkgName.split('.')
>> moduleNames.reverse()
>> for mName in moduleNames:
>> mIdx = path.rfind(mName)
>> basePath = basePath[:mIdx]
>> pkgPath = path[len(basePath):]
>> else:
>> # this is a package linked in as externals
>> basePath = path[:srcIdx]
>> pkgPath = path[len(basePath):]
>>
>> I don't understand why we need different code for "packages
>> linked in as externals". The "egg package" code works
>> actually better for linked in packages that don't follow the
>> 'src' convention.
>>
>> Proposal: Use the 'if' code for all packages.
>
> I was fighting several times with this part during coding.
> The only thing which this part has to make sure is that
> we do not use anything outside of the package in our path.
>
> The reason for not including everything outside the package
> in our path is that such a path whould be depend on the
> local setup e.g.
>
> D:\foo\dev\zope\session:3
>
> We only have to make sure that this never will happen and that
> we for each use case generate path like:
>
> zope/session.py:3
>
> It could be that the if part is working for all usecases.
> but I'n not sure without debugging.
Debugging doesn't help much if we don't know all use cases.
What about testing it like this:
We remove the 'else' part and wait until someone complains. In that case
we have a scenario for testing and fixing the issue. If nobody
complains, the 'else' part was indeed useless.
The current code doesn't work for me because 'src' is found but not the
right place to split the path.
Cheers,
Yuppie
___
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 )
Re: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi yuppie
> -Ursprüngliche Nachricht-
> Von: zope-dev-bounces+dev=projekt01...@zope.org
> [mailto:zope-dev-bounces+dev=projekt01...@zope.org] Im
> Auftrag von yuppie
> Gesendet: Mittwoch, 15. Juli 2009 21:04
> An: Zope-Dev List
> Betreff: [Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
>
> Hi!
>
>
> I plan to use z3c.recipe.i18n for some Zope 2 CMF products.
> But to get things working I did have to modify z3c.recipe.i18n a bit.
>
> It would be nice if I could get some feedback regarding the
> issues I found:
>
> 1.) running tests
> -
>
> test.py tries to install 'zodbcode' and 'zope.app.interface'.
> That doesn't work for me. AFAICS those two eggs are no longer
> indirect testing dependencies. After removing those two lines
> all tests pass.
>
> Proposal: Remove those two lines in test.py.
That's fine
> 2.) looking up the product version
> --
>
> POTMaker._getProductVersion() doesn't work for me.
> zope.app.applicationcontrol is not used by Zope 2 and is not
> part of the specified dependencies. This raises an error.
>
> Proposal: Catch the error. Return an empty string if version
> is not found.
Sounds good to me as a workarround
Probably we should try to use the package version of the egg
which uses the i18n recipe?
> 3.) customizing the .pot header
> ---
>
> POTMaker.write() uses a harcoded Zope 3 specific pot_header template.
>
> Proposal: The easiest and most flexible way to customize this
> seems to be an option that allows to specify a file that
> contains the pot_header template.
Yeah, that's a nice option
> 4.) looking up basePath
> ---
>
> i18nextract.main() contains these lines:
>
> # add maker for each given path
> for pkgName, path in eggPaths:
> srcIdx = path.rfind('src')
> if srcIdx == -1:
> # this is an egg package, strip down base path
> basePath = path
> moduleNames = pkgName.split('.')
> moduleNames.reverse()
> for mName in moduleNames:
> mIdx = path.rfind(mName)
> basePath = basePath[:mIdx]
> pkgPath = path[len(basePath):]
> else:
> # this is a package linked in as externals
> basePath = path[:srcIdx]
> pkgPath = path[len(basePath):]
>
> I don't understand why we need different code for "packages
> linked in as externals". The "egg package" code works
> actually better for linked in packages that don't follow the
> 'src' convention.
>
> Proposal: Use the 'if' code for all packages.
I was fighting several times with this part during coding.
The only thing which this part has to make sure is that
we do not use anything outside of the package in our path.
The reason for not including everything outside the package
in our path is that such a path whould be depend on the
local setup e.g.
D:\foo\dev\zope\session:3
We only have to make sure that this never will happen and that
we for each use case generate path like:
zope/session.py:3
It could be that the if part is working for all usecases.
but I'n not sure without debugging.
> 5. writing makers
> -
>
> I'd like to specify additional makers. This is a nice hook,
> but why are only these three arguments passed to custom poMakers?
>
> maker.add(poMaker(path, basePath, exclude_dirs),
> basePath)
>
> I miss 'domain' and 'include_default_domain'.
>
> Proposal: Pass in the additional arguments and fall back to
> the old signature for BBB.
>
>
> Does all that make sense? Any objections or better ideas?
>
> Should changes for POTMaker go into zope.app.locales.extract
> or should
> z3c.recipe.i18n use a customized version?
I think it's probably the best idea to enhance the
method signature in zope.app.locales.extract if this
is possible without to break compatibiliy.
Yes, everything makes sense to me.
Thanks a lot yuppie,
this are very good improvments for z3c.recipe.i18n
Regards
Roger Ineichen
___
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 )
[Zope-dev] z3c.recipe.i18n and zope.app.locales.extract
Hi!
I plan to use z3c.recipe.i18n for some Zope 2 CMF products. But to get
things working I did have to modify z3c.recipe.i18n a bit.
It would be nice if I could get some feedback regarding the issues I found:
1.) running tests
-
test.py tries to install 'zodbcode' and 'zope.app.interface'. That
doesn't work for me. AFAICS those two eggs are no longer indirect
testing dependencies. After removing those two lines all tests pass.
Proposal: Remove those two lines in test.py.
2.) looking up the product version
--
POTMaker._getProductVersion() doesn't work for me.
zope.app.applicationcontrol is not used by Zope 2 and is not part of the
specified dependencies. This raises an error.
Proposal: Catch the error. Return an empty string if version is not found.
3.) customizing the .pot header
---
POTMaker.write() uses a harcoded Zope 3 specific pot_header template.
Proposal: The easiest and most flexible way to customize this seems to
be an option that allows to specify a file that contains the pot_header
template.
4.) looking up basePath
---
i18nextract.main() contains these lines:
# add maker for each given path
for pkgName, path in eggPaths:
srcIdx = path.rfind('src')
if srcIdx == -1:
# this is an egg package, strip down base path
basePath = path
moduleNames = pkgName.split('.')
moduleNames.reverse()
for mName in moduleNames:
mIdx = path.rfind(mName)
basePath = basePath[:mIdx]
pkgPath = path[len(basePath):]
else:
# this is a package linked in as externals
basePath = path[:srcIdx]
pkgPath = path[len(basePath):]
I don't understand why we need different code for "packages linked in as
externals". The "egg package" code works actually better for linked in
packages that don't follow the 'src' convention.
Proposal: Use the 'if' code for all packages.
5. writing makers
-
I'd like to specify additional makers. This is a nice hook, but why are
only these three arguments passed to custom poMakers?
maker.add(poMaker(path, basePath, exclude_dirs), basePath)
I miss 'domain' and 'include_default_domain'.
Proposal: Pass in the additional arguments and fall back to the old
signature for BBB.
Does all that make sense? Any objections or better ideas?
Should changes for POTMaker go into zope.app.locales.extract or should
z3c.recipe.i18n use a customized version?
Cheers,
Yuppie
___
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 )
