Mailing List Archive: Zope: Dev

New i18n locale extraction concept

Index | Next | Previous | View Threaded

dev at projekt01

Apr 30, 2008, 5:06 PM

Post #1 of 25 (1231 views)
Permalink

New i18n locale extraction concept

Hi all

I added a new package for extract i18n locales
and I have some questions.

Is it posible to split the zope.app.locales
package into a package which offers the
interfaces and classes e.g. PotMaker,
the generic extract.py file and another one
which provides the translation for zope.app?

Right now the zope.app.locales offers the API
for extract locales messages and at the same time
it offers the translations for zope.app packages.
Also the hole locale extraction is still based on
the old style trunk setup and is not useable for egg
based projects.

The new package which I implemented in z3c.recipe.i18n
can extract locales straight from released eggs or
from linked in develop externals.

What does this mean?
The locale extraction is now a part of a recipe
and not a part of a package itself.

My goal is to remove the dependencies in the
z3c.recipe.i18n, because right now it uses the
base implementation in zope.app.locales which makes
it depend on the hole zope namepsace. Because of
the overall zope.* dependenc in zope.app.locale.

The best option whould be to split zope.app.locales
into usefull packages. The not so good optipon whould
be to copy over the relevant classes and scripts to
the recipe and skip the dependency to zope.app.locale.

I also started to use the recipe in z3c.locales
and zam.locales. Take a look at this package for
a real usecase.

What do you think? Should we switch the locale extraction
to that concept for the zope.* packages too or not?

Regards
Roger Ineichen
_____________________________
END OF MESSAGE

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

plone at hannosch

May 1, 2008, 1:11 AM

Post #2 of 25 (1202 views)
Permalink

Re: New i18n locale extraction concept [In reply to]

Hi.

Roger Ineichen wrote:
> I added a new package for extract i18n locales
> and I have some questions.
>
> Is it posible to split the zope.app.locales
> package into a package which offers the
> interfaces and classes e.g. PotMaker,
> the generic extract.py file and another one
> which provides the translation for zope.app?

+1, right now I copied over the extract.py and interfaces.py to my
i18ndude package, to avoid the zope.app dependency. The remaining
dependencies on zope.i18n/messageid and zope.tal are perfectly
reasonable IMO.

I also had to make some adjustment where the code wheren't flexible
enough, which I would like to merge back into the main line or the new
package.

I'm not good with names, but something like zope.i18nextract would work
for me.

Hanno

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

cz at gocept

May 1, 2008, 2:27 AM

Post #3 of 25 (1198 views)
Permalink

Re: New i18n locale extraction concept [In reply to]

On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev[at]projekt01.ch> said:
>
>
> What does this mean?
> The locale extraction is now a part of a recipe
> and not a part of a package itself.
>
> My goal is to remove the dependencies in the
> z3c.recipe.i18n, because right now it uses the
> base implementation in zope.app.locales which makes
> it depend on the hole zope namepsace. Because of
> the overall zope.* dependenc in zope.app.locale.

Actually, there is lovely.receipe:i18n which provides i18n extraction.
Does z3c.recipe.i18n something else or why is there yet another i18n
recipe?

> The best option whould be to split zope.app.locales
> into usefull packages. The not so good optipon whould
> be to copy over the relevant classes and scripts to
> the recipe and skip the dependency to zope.app.locale.
>
> I also started to use the recipe in z3c.locales
> and zam.locales. Take a look at this package for
> a real usecase.
>
> What do you think? Should we switch the locale extraction
> to that concept for the zope.* packages too or not?

Exctaction should be in a recipe, of course. But I'm also advocating
for having the translations in the package and having one domain per
package. `

--
Christian Zagrodnick

gocept gmbh & co. kg · forsterstrasse 29 · 06112 halle/saale
www.gocept.com · fon. +49 345 12298894 · fax. +49 345 12298891

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

ccomb at free

May 1, 2008, 5:25 AM

Post #4 of 25 (1196 views)
Permalink

Re: Re: New i18n locale extraction concept [In reply to]

Christian Zagrodnick a Ã©crit :
> On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev[at]projekt01.ch> said:
>>
>>
>> What does this mean?
>> The locale extraction is now a part of a recipe
>> and not a part of a package itself.
>>
>> My goal is to remove the dependencies in the
>> z3c.recipe.i18n, because right now it uses the
>> base implementation in zope.app.locales which makes
>> it depend on the hole zope namepsace. Because of
>> the overall zope.* dependenc in zope.app.locale.
>
> Actually, there is lovely.receipe:i18n which provides i18n extraction.
> Does z3c.recipe.i18n something else or why is there yet another i18n
> recipe?
>
>
>> The best option whould be to split zope.app.locales
>> into usefull packages. The not so good optipon whould
>> be to copy over the relevant classes and scripts to
>> the recipe and skip the dependency to zope.app.locale.
>>
>> I also started to use the recipe in z3c.locales
>> and zam.locales. Take a look at this package for
>> a real usecase.
>>
>> What do you think? Should we switch the locale extraction
>> to that concept for the zope.* packages too or not?
>
> Exctaction should be in a recipe, of course. But I'm also advocating for
> having the translations in the package and having one domain per package. `

One drawback of this, is that it will be a pain for translators to gather and
update translations, unless a tool is provided. Currently with only one file,
there is already few languages. It's much more efficient for translators to work
on one single big file than a lot of small ones.

It will also prevent from using one same translation at different places, and
identical messages will have to be translated several times, with the risk of
not being consistent across packages. Unless everything is done by one person,
using a translation memory.

It seems obvious and logical to split the translation domains, but we need to
provide a tool such as http://translationproject.org/extra/matrix.html
that will allow
- the package developer to submit a new POT file (by mail, upload, or anything)
- translators to quickly see what need to be done and submit updated POs

Ideally, the recipe i18n tool should be able to extract, merge, and give stats,
just like in the monolithic zope release.

Christophe

>

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

dev at projekt01

May 1, 2008, 2:23 PM

Post #5 of 25 (1186 views)
Permalink

AW: Re: New i18n locale extraction concept [In reply to]

Hi Christian

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

[...]

> > My goal is to remove the dependencies in the
> z3c.recipe.i18n, because
> > right now it uses the base implementation in zope.app.locales which
> > makes it depend on the hole zope namepsace. Because of the overall
> > zope.* dependenc in zope.app.locale.
>
> Actually, there is lovely.receipe:i18n which provides i18n
> extraction.
> Does z3c.recipe.i18n something else or why is there yet
> another i18n recipe?

Yes, I was using this recipe but it only works if the locales is
a part of a package. It's not possible to extract translations
from different packages into a own locales package.

Note:
the -d option use a path in the original i8nextract.py
my new version uses egg or develop externals package as
-d option. And allows to extract from different packages
into a single *.locales package.

> > The best option whould be to split zope.app.locales
> > into usefull packages. The not so good optipon whould
> > be to copy over the relevant classes and scripts to
> > the recipe and skip the dependency to zope.app.locale.
> >
> > I also started to use the recipe in z3c.locales
> > and zam.locales. Take a look at this package for
> > a real usecase.
> >
> > What do you think? Should we switch the locale extraction
> > to that concept for the zope.* packages too or not?
>
> Exctaction should be in a recipe, of course. But I'm also advocating
> for having the translations in the package and having one domain per
> package. `

Sometimes yes, soemtimes no. I think a own domain for
pckages lie z3c.form is Ok. But I think we also need a
shared domain for packages whihc only need to translate
one, tow or a small amount of message ids.

The benefit of a shared domain is the following:
If someone speaking polnish or some other langauge then
english and uses one or two packages he is probably willing to
translate this packages. If we use a shared domain including
the translation for a larger setup of packages, he is probably
willing to translate all of them because he allready started
the setup and beginns to translate.

Regards
Roger Ineichen

> --
> Christian Zagrodnick
>
> gocept gmbh & co. kg . forsterstrasse 29 . 06112 halle/saale
> www.gocept.com . fon. +49 345 12298894 . fax. +49 345 12298891

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

dev at projekt01

May 1, 2008, 2:29 PM

Post #6 of 25 (1185 views)
Permalink

AW: Re: New i18n locale extraction concept [In reply to]

Hi Hanno

> Betreff: [Zope-dev] Re: New i18n locale extraction concept
>
> Hi.
>
> Roger Ineichen wrote:
> > I added a new package for extract i18n locales and I have some
> > questions.
> >
> > Is it posible to split the zope.app.locales package into a package
> > which offers the interfaces and classes e.g. PotMaker, the generic
> > extract.py file and another one which provides the translation for
> > zope.app?
>
> +1, right now I copied over the extract.py and interfaces.py to my
> i18ndude package, to avoid the zope.app dependency. The
> remaining dependencies on zope.i18n/messageid and zope.tal
> are perfectly reasonable IMO.

Yes

> I also had to make some adjustment where the code wheren't
> flexible enough, which I would like to merge back into the
> main line or the new package.

The main changes in the new concept is, that it uses egg or
develop externals as -d option and theoriginal package uses
path for the -d option.

I think both concept could stay intact. The recipe could be used
for extract locales for egg based packages and the original
could be used for locales which are a part of the package itself.

This whould avoid confusing others

> I'm not good with names, but something like zope.i18nextract
> would work for me.

+1, that's fine for me

> Hanno
>
> _______________________________________________
> 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 )
>

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

dev at projekt01

May 1, 2008, 2:38 PM

Post #7 of 25 (1183 views)
Permalink

AW: Re: New i18n locale extraction concept [In reply to]

Hi Christophe

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

[....]

> >> The best option whould be to split zope.app.locales into usefull
> >> packages. The not so good optipon whould be to copy over
> the relevant
> >> classes and scripts to the recipe and skip the dependency to
> >> zope.app.locale.
> >>
> >> I also started to use the recipe in z3c.locales and
> zam.locales. Take
> >> a look at this package for a real usecase.
> >>
> >> What do you think? Should we switch the locale extraction to that
> >> concept for the zope.* packages too or not?
> >
> > Exctaction should be in a recipe, of course. But I'm also
> advocating
> > for having the translations in the package and having one
> domain per
> > package. `
>
> One drawback of this, is that it will be a pain for
> translators to gather and update translations, unless a tool
> is provided. Currently with only one file, there is already
> few languages. It's much more efficient for translators to
> work on one single big file than a lot of small ones.

+1, that's the main reason why I preferre shared domains
in packages. Sometimes I only have one or two message ids
which I think should stay in a shared domain.pot file rather
then add a new domainn for them.

Of corse a large amount of message ids in a z3c.* package
can still provide a own domain. That's allways a valid option.

My main point of view is the translator which have to speak
a language. In his point of view it's simpler to have a single
file instead of handling all the different packages he probaly
doesn't even use.

> It will also prevent from using one same translation at
> different places, and identical messages will have to be
> translated several times, with the risk of not being
> consistent across packages. Unless everything is done by one
> person, using a translation memory.

+1, very good ideas!

> It seems obvious and logical to split the translation
> domains, but we need to provide a tool such as
> http://translationproject.org/extra/matrix.html
> that will allow
> - the package developer to submit a new POT file (by mail,
> upload, or anything)
> - translators to quickly see what need to be done and submit
> updated POs

I agree, a tool whould be great. But the first we need to
offer i18n extract script which can handle our new egg
based buildout process. z3c.recipe.i18n is the only one
which could handle this right now.

> Ideally, the recipe i18n tool should be able to extract,
> merge, and give stats, just like in the monolithic zope release.

Yes, z3c.recipe.i18n does this right now. The -d option uses
one or more egg or develop externals as argument instead of
one single path.

> Christophe
>
> >
>
> _______________________________________________
> 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 )
>

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

m.van.rees at zestsoftware

May 6, 2008, 3:24 PM

Post #8 of 25 (1122 views)
Permalink

Re: New i18n locale extraction concept [In reply to]

Christian Zagrodnick, on 2008-05-01:
> On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev[at]projekt01.ch> said:
>>
>>
>> What does this mean?
>> The locale extraction is now a part of a recipe
>> and not a part of a package itself.
>>
>> My goal is to remove the dependencies in the
>> z3c.recipe.i18n, because right now it uses the
>> base implementation in zope.app.locales which makes
>> it depend on the hole zope namepsace. Because of
>> the overall zope.* dependenc in zope.app.locale.
>
> Actually, there is lovely.receipe:i18n which provides i18n extraction.
> Does z3c.recipe.i18n something else or why is there yet another i18n
> recipe?

For me a downside of lovely.recipe:i18n is that it has too many
dependencies: the whole of zope. When easy installing it in a virtual
env, you end up with 44 MB of eggs.

For comparison, easy installing i18ndude needs about 6 MB.

See this (currently) small thread in grok-dev:
http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742

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

dev at projekt01

May 7, 2008, 3:51 AM

Post #9 of 25 (1111 views)
Permalink

AW: Re: New i18n locale extraction concept [In reply to]

Hi Maurits

> Betreff: [Zope-dev] Re: New i18n locale extraction concept
>
> Christian Zagrodnick, on 2008-05-01:
> > On 2008-05-01 02:06:17 +0200, "Roger Ineichen"
> <dev[at]projekt01.ch> said:
> >>
> >>
> >> What does this mean?
> >> The locale extraction is now a part of a recipe and not a
> part of a
> >> package itself.
> >>
> >> My goal is to remove the dependencies in the
> z3c.recipe.i18n, because
> >> right now it uses the base implementation in
> zope.app.locales which
> >> makes it depend on the hole zope namepsace. Because of the overall
> >> zope.* dependenc in zope.app.locale.
> >
> > Actually, there is lovely.receipe:i18n which provides i18n
> extraction.
> > Does z3c.recipe.i18n something else or why is there yet
> another i18n
> > recipe?
>
> For me a downside of lovely.recipe:i18n is that it has too many
> dependencies: the whole of zope. When easy installing it in
> a virtual env, you end up with 44 MB of eggs.
>
> For comparison, easy installing i18ndude needs about 6 MB.

Yes, that's what I was asking for. The zope.app.locales
has dependencies to each i18n aware zope.* package because it
offers transalation for this packages. And at the same time
it offers the i18nextract.py script which could be used by
other projects. This ends in having dependencies to all
zope.* packages. We need to split the locale extraction
concept and the concret zope.* package extraction part into
two different packages. Then we can reuse the local extraction
concept wihtout dependencies to the full zope.* package tree.

Regards
Roger Ineichen

> See this (currently) small thread in grok-dev:
> http://thread.gmane.org/gmane.comp.web.zope.grok.devel/4742
>
> --
> 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 )
>

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

m.van.rees at zestsoftware

May 7, 2008, 3:13 PM

Post #10 of 25 (1101 views)
Permalink

Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi Roger,

Roger Ineichen, on 2008-05-01:
> I agree, a tool whould be great. But the first we need to
> offer i18n extract script which can handle our new egg
> based buildout process. z3c.recipe.i18n is the only one
> which could handle this right now.
>
>> Ideally, the recipe i18n tool should be able to extract,
>> merge, and give stats, just like in the monolithic zope release.
>
> Yes, z3c.recipe.i18n does this right now. The -d option uses
> one or more egg or develop externals as argument instead of
> one single path.

Some comments on that z3c.recipe.i18n

In README.txt you first mention z3c.recipe.start, then the i18n recipe
and then the app recipe. Is the same meant in all three cases?

I like that it can extract locales from eggs. I don't like that it
uses zcml for this. Is the zcml really necessary?

Why specify both eggs and packages? And why specify those packages in
the setup.py too? At least that is what I see in zam.locales.

The tests don't run on Linux as there are Windows specific checks in
them, for example:

File ".../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt", line 121,
in README.txt
Failed example:
ls('bin')
Expected:
- buildout-script.py
- buildout.exe
- i18nextract-script.py
- i18nextract.exe
- i18nmergeall-script.py
- i18nmergeall.exe
- i18nstats-script.py
- i18nstats.exe
Got:
- buildout
- i18nextract
- i18nmergeall
- i18nstats

Of course quite likely there are also a lot of Linux/Mac packages that
fail on Windows because of similar reasons. :-/

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

dev at projekt01

May 7, 2008, 3:55 PM

Post #11 of 25 (1102 views)
Permalink

AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi Maurits

Thanks for your feedback,

> Betreff: [Zope-dev] Re: AW: Re: New i18n locale extraction concept
>
> Hi Roger,
>
> Roger Ineichen, on 2008-05-01:
> > I agree, a tool whould be great. But the first we need to
> offer i18n
> > extract script which can handle our new egg based buildout process.
> > z3c.recipe.i18n is the only one which could handle this right now.
> >
> >> Ideally, the recipe i18n tool should be able to extract,
> merge, and
> >> give stats, just like in the monolithic zope release.
> >
> > Yes, z3c.recipe.i18n does this right now. The -d option uses one or
> > more egg or develop externals as argument instead of one
> single path.
>
> Some comments on that z3c.recipe.i18n
>
> In README.txt you first mention z3c.recipe.start, then the
> i18n recipe and then the app recipe. Is the same meant in
> all three cases?

Uhaaa, that's a left over from a copied README.txt file.
I need to review that part again.

> I like that it can extract locales from eggs. I don't like
> that it uses zcml for this. Is the zcml really necessary?

zcml is needed for exctract locales from page templates.

> Why specify both eggs and packages? And why specify those
> packages in the setup.py too? At least that is what I see in
> zam.locales.

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.

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.

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.

> The tests don't run on Linux as there are Windows specific
> checks in them, for example:
>
> File ".../z3c.recipe.i18n/src/z3c/recipe/i18n/README.txt", line 121,
> in README.txt
> Failed example:
> ls('bin')
> Expected:
> - buildout-script.py
> - buildout.exe
> - i18nextract-script.py
> - i18nextract.exe
> - i18nmergeall-script.py
> - i18nmergeall.exe
> - i18nstats-script.py
> - i18nstats.exe
> Got:
> - buildout
> - i18nextract
> - i18nmergeall
> - i18nstats
>
> Of course quite likely there are also a lot of Linux/Mac
> packages that fail on Windows because of similar reasons. :-/

I see, I 'll add a normalizer for that. I thought it was already
there, but could be not correct implemented.

Regards
Roger Ineichen

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

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

srichter at cosmos

May 8, 2008, 8:07 AM

Post #12 of 25 (1071 views)
Permalink

Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On Wednesday 07 May 2008, Roger Ineichen wrote:
> > I like that it can extract locales from eggs. I don't like
> > that it uses zcml for this. Is the zcml really necessary?
>
> zcml is needed for exctract locales from page templates.

ZCML is needed to extract strings from ZCML.

Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
_______________________________________________
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 )

m.van.rees at zestsoftware

May 8, 2008, 9:55 AM

Post #13 of 25 (1065 views)
Permalink

Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Stephan Richter, on 2008-05-08:
> On Wednesday 07 May 2008, Roger Ineichen wrote:
>> > I like that it can extract locales from eggs. I don't like
>> > that it uses zcml for this. Is the zcml really necessary?
>>
>> zcml is needed for exctract locales from page templates.
>
> ZCML is needed to extract strings from ZCML.

I am looking at maybe using this recipe in grokproject. Having that
zcml be *required* (which it currently is in that recipe) is a no-no
for us simple Grok folks. ;-)

I hope it is possible to remove that zcml requirement; the recipe is
still young, so who knows. I am also looking at i18ndude for that, as
that is what I have been using in Plone-land so far. Might work
nicely in the Grok-cave too.

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

m.van.rees at zestsoftware

May 8, 2008, 10:16 AM

Post #14 of 25 (1063 views)
Permalink

Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi Roger,

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

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

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 )

dev at projekt01

May 8, 2008, 4:08 PM

Post #15 of 25 (1058 views)
Permalink

AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi Maurits

> -----Ursprüngliche Nachricht-----
> Von: zope-dev-bounces[at]zope.org
> [mailto:zope-dev-bounces[at]zope.org] Im Auftrag von Maurits van Rees
> Gesendet: Donnerstag, 8. Mai 2008 18:55
> An: zope-dev[at]zope.org
> Betreff: [Zope-dev] Re: AW: Re: AW: Re: New i18n locale
> extraction concept
>
> Stephan Richter, on 2008-05-08:
> > On Wednesday 07 May 2008, Roger Ineichen wrote:
> >> > I like that it can extract locales from eggs. I don't
> like that it
> >> > uses zcml for this. Is the zcml really necessary?
> >>
> >> zcml is needed for exctract locales from page templates.
> >
> > ZCML is needed to extract strings from ZCML.
>
> I am looking at maybe using this recipe in grokproject.
> Having that zcml be *required* (which it currently is in that
> recipe) is a no-no for us simple Grok folks. ;-)
>
> I hope it is possible to remove that zcml requirement; the
> recipe is still young, so who knows. I am also looking at
> i18ndude for that, as that is what I have been using in
> Plone-land so far. Might work nicely in the Grok-cave too.

The goal of this package is to allow to translate projects
or shared translation from package namspaces which was not
possible right now.

I see your point not having zcml but that's a no go for use
since most zope project are using ZCML. But probably we can
find a way out of this. I really need to take a closer look
at everything first.

Some hints, the package offers translation support and uses
additional extra_requires for the configuration. In prodution
you whould never define such extra_requires in a buildout
and then you will never get such zcml dependencies.

Does that not fit for grok. Or are you using the same buildout
for development and production usage? I hope not right?

Regards
Roger Ineichen

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

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

dev at projekt01

May 8, 2008, 4:32 PM

Post #16 of 25 (1056 views)
Permalink

AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

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

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

jh at improva

May 9, 2008, 1:59 AM

Post #17 of 25 (1035 views)
Permalink

Re: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi,

Roger Ineichen wrote:
>>> 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.
>
That sounds suspiciously like you are trying to import the
modules/packages that you want to extract from. I think that is neither
necessary nor desirable. The extraction should work on the source code
only. For zcml extraction, that might be an issue because knowing which
strings to extract requires processing the meta directives included from
the file. For python source code and page templates there is no such
problem.

Hope this helps,

Jacob

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

srichter at cosmos

May 9, 2008, 4:37 AM

Post #18 of 25 (1034 views)
Permalink

Re: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On Thursday 08 May 2008, Roger Ineichen wrote:
> > 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
> )

You do not need a running environment for the Python message extractions; you
need it for ZCML (I think). Python is extracted using the parser module and
looking for _ function calls with a string in it.

Regards,
Stephan
--
Stephan Richter
Web Software Design, Development and Training
Google me. "Zope Stephan Richter"
_______________________________________________
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 )

dev at projekt01

May 9, 2008, 6:18 AM

Post #19 of 25 (1033 views)
Permalink

AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi Stephan

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

[...]

> > 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
> > )
>
> You do not need a running environment for the Python message
> extractions; you need it for ZCML (I think). Python is
> extracted using the parser module and looking for _ function
> calls with a string in it.

Yes, I probably explaind it wrong.
The above sample fails because it stops the extraction if it
loads the zcml. The module foo.bar must be available if the
schema/field is used in a class or other ZCML directives.
I guess other extraction concept will work with missing imports.

Anyway, Since zcml is a default part of zope locale extraction
it make no sense to me to not using a working setup for
locale extraction. Grok? Does Grok not use zcml extraction?
If not, we could probably change the z3c.recipe and disable
the default zcml extractor.

btw, with a working setup I don't talk about a running server.
But at least all dependent packages should be there. And since
we have a buildout concept, I think it's the simplest way to
setup such dependencies and provide a working set.

Regards
Roger Ineichen

> Regards,
> Stephan
> --
> Stephan Richter
> Web Software Design, Development and Training Google me.
> "Zope Stephan Richter"
>

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

plone at hannosch

May 10, 2008, 6:40 AM

Post #20 of 25 (998 views)
Permalink

Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Hi.

Roger Ineichen wrote:
> Anyway, Since zcml is a default part of zope locale extraction
> it make no sense to me to not using a working setup for
> locale extraction. Grok? Does Grok not use zcml extraction?
> If not, we could probably change the z3c.recipe and disable
> the default zcml extractor.

Currently i18ndude doesn't extract any messages from ZCML. It is used
for extraction of all messages for the Plone project which happens to
use lots of ZCML. But none of the messages defined in ZCML are actually
used in any user visible part of the whole application.

So even if you are a Zope project, I think there's very good reasons not
to require ZCML extraction.

Hanno

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

mj at zopatista

May 10, 2008, 9:04 AM

Post #21 of 25 (993 views)
Permalink

Re: Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting <plone[at]hannosch.info> wrote:
> Currently i18ndude doesn't extract any messages from ZCML. It is used for
> extraction of all messages for the Plone project which happens to use lots
> of ZCML. But none of the messages defined in ZCML are actually used in any
> user visible part of the whole application.
>
> So even if you are a Zope project, I think there's very good reasons not to
> require ZCML extraction.

Although the ZMI may not count as a 'user visible' part, Generic Setup
profile titles do show up there, which are defined in ZCML and should
be translatable.

Also, these days it is possible to register content views (such as the
default view for a folder) through ZCML, using a menu directive for
the title. Again these titles should be translatable.

--
Martijn Pieters
_______________________________________________
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 )

wichert at wiggy

May 10, 2008, 9:22 AM

Post #22 of 25 (991 views)
Permalink

Re: Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

Previously Martijn Pieters wrote:
> On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting <plone[at]hannosch.info> wrote:
> > Currently i18ndude doesn't extract any messages from ZCML. It is used for
> > extraction of all messages for the Plone project which happens to use lots
> > of ZCML. But none of the messages defined in ZCML are actually used in any
> > user visible part of the whole application.
> >
> > So even if you are a Zope project, I think there's very good reasons not to
> > require ZCML extraction.
>
> Although the ZMI may not count as a 'user visible' part, Generic Setup
> profile titles do show up there, which are defined in ZCML and should
> be translatable.
>
> Also, these days it is possible to register content views (such as the
> default view for a folder) through ZCML, using a menu directive for
> the title. Again these titles should be translatable.

zcml is a pretty simple format though: xml with only human readable text
in title and description attributes (and perhaps a few others) and the
translation domain specified in a i18n_domain attribute. It should be
quite trivial to extract that data without having to pull all of zope
in.

Wichert.

--
Wichert Akkerman <wichert[at]wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
_______________________________________________
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 )

mj at zopatista

May 10, 2008, 10:38 AM

Post #23 of 25 (989 views)
Permalink

Re: Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman <wichert[at]wiggy.net> wrote:
> zcml is a pretty simple format though: xml with only human readable text
> in title and description attributes (and perhaps a few others) and the
> translation domain specified in a i18n_domain attribute. It should be
> quite trivial to extract that data without having to pull all of zope
> in.

If you determine beforehand which strings are translatable (end up as
msgid objects) it should be trivial to extract these. You will have to
update i18ndude to add new zcml tags though.

--
Martijn Pieters
_______________________________________________
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 )

cz at gocept

May 20, 2008, 6:39 AM

Post #24 of 25 (742 views)
Permalink

Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On 2008-05-10 19:38:15 +0200, "Martijn Pieters" <mj[at]zopatista.com> said:

> On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman <wichert[at]wiggy.net> wrote:
>> zcml is a pretty simple format though: xml with only human readable text
>> in title and description attributes (and perhaps a few others) and the
>> translation domain specified in a i18n_domain attribute. It should be
>> quite trivial to extract that data without having to pull all of zope
>> in.
>
> If you determine beforehand which strings are translatable (end up as
> msgid objects) it should be trivial to extract these. You will have to
> update i18ndude to add new zcml tags though.

What's translatable and what not is defined by the schema of the
configuration which can be extended by any package. So adding this
information to the extractor would duplicate it. Not good.

--
Christian Zagrodnick · cz[at]gocept.com
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 4 · fax +49 345 1229889 1
Zope and Plone consulting and development

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

mj at zopatista

May 20, 2008, 7:08 AM

Post #25 of 25 (741 views)
Permalink

Re: Re: AW: AW: Re: AW: Re: AW: Re: New i18n locale extraction concept [In reply to]

On Tue, May 20, 2008 at 3:39 PM, Christian Zagrodnick <cz[at]gocept.com> wrote:
>> If you determine beforehand which strings are translatable (end up as
>> msgid objects) it should be trivial to extract these. You will have to
>> update i18ndude to add new zcml tags though.
>
> What's translatable and what not is defined by the schema of the
> configuration which can be extended by any package. So adding this
> information to the extractor would duplicate it. Not good.

But extracting that information may be prohibitively difficult and
expensive to do.

--
Martijn Pieters
_______________________________________________
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 )

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com