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 )
[Zope-dev] Zope Tests: 2 OK, 4 Failed
Summary of messages to the zope-tests list. Period Wed Jul 15 12:00:00 2009 UTC to Thu Jul 16 12:00:00 2009 UTC. There were 6 messages: 6 from Zope Tests. Test failures - Subject: FAILED (failures=1) : Zope-2.12 Python-2.6.2 : Linux From: Zope Tests Date: Wed Jul 15 20:41:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012069.html Subject: FAILED (failures=7) : Zope-2.12-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Jul 15 20:43:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012070.html Subject: FAILED (failures=1) : Zope-trunk Python-2.6.2 : Linux From: Zope Tests Date: Wed Jul 15 20:45:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012071.html Subject: FAILED (failures=7) : Zope-trunk-alltests Python-2.6.2 : Linux From: Zope Tests Date: Wed Jul 15 20:47:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012072.html Tests passed OK --- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Wed Jul 15 20:37:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012067.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Wed Jul 15 20:39:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-July/012068.html ___ 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 )
