AW: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale extraction concept

[Roger Ineichen]

Hi Maurits

> Betreff: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale 
> extraction concept

[...]

> > 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 check it.

I will take a look on that. Probably we can implement some rules for 
that if something is not defined.

> > 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.")

Probably it works in some ues case but for sure not in all.
Let's give a sample. If you define a interface like

foo = zope.schema.Choice(
    title=_('Title'),
    vocabulary=foo.bar.myVocabularyFromPackageFoo
    )


Then the foo.bar package must be available. 

Another use case is if you use a product configuration like:

def storagePath():
    path = None
    config = getProductConfiguration('p01.fsfile')
    if config is not None:
        path = config.get('fsstorage')
    else:
        raise ValueError(
            "You must define p01.fsfile 'fsstorage' for run this server")
    return str(path)

The above sample needs to know about the fsstorage, otherwise you 
will run into a ValueError during locale extraction which will abort 
the extraction process.

The same is true for grok. If gork defines something in a module
which raises an exception if not available, it will run into an
error and abort.

I strongly recommend to use a real working setup if you extract
locales. The egg attribute supports such a setup.
The package attributes defines which package should get used
for deep into and extract from.

Note, it doesn't mean that every package must fail, but it's just 
not what we should propose because it's not guaranteed that this 
will work.

btw,
the sample in zaml.locales uses as egg zam.locales [extract]
which is a single line and uses the extra_requires from the 
setup.py in zam.locales. In a poduction setup you whould never
use that extra_requires whihc should be fine.

> > 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.

The main goal is to have somethig for shared i18n message factories
like used in some z3c package and I guess others have in thier
custom projects. Of corse, if there is a way we should make it fit 
for other use cases too.

> 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 me know.

Ok, will make progress on that next week. I let you know
if somehting is ready. I really appreciate your help and 
comments and hope that we could make the recipe fit for 
zope, z3c and grok.

Thanks
Roger Ineichen

> 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 at 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 )
>