[Zope-dev] z3c.recipe.i18n and zope.app.locales.extract

[Roger Ineichen]

Hi yuppie
  

> -----Ursprüngliche Nachricht-----
> Von: zope-dev-bounces+dev=projekt01.ch at zope.org 
> [mailto:zope-dev-bounces+dev=projekt01.ch at 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