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
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
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@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 )
On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev@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
Christian Zagrodnick a écrit :
On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev@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
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@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 )
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]
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@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 )
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"
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]
Hi Maurits
-----Ursprüngliche Nachricht----- Von: zope-dev-bounces@zope.org [mailto:zope-dev-bounces@zope.org] Im Auftrag von Maurits van Rees Gesendet: Donnerstag, 8. Mai 2008 18:55 An: zope-dev@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@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 )
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]
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@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 )
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
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"
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"
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
On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting <plone@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
Previously Martijn Pieters wrote:
On Sat, May 10, 2008 at 3:40 PM, Hanno Schlichting <plone@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@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman <wichert@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
On 2008-05-10 19:38:15 +0200, "Martijn Pieters" <mj@zopatista.com> said:
On Sat, May 10, 2008 at 6:22 PM, Wichert Akkerman <wichert@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@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
On Tue, May 20, 2008 at 3:39 PM, Christian Zagrodnick <cz@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
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
Christian Zagrodnick, on 2008-05-01:
On 2008-05-01 02:06:17 +0200, "Roger Ineichen" <dev@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]
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@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@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 )
participants (9)
-
Christian Zagrodnick -
Christophe Combelles -
Hanno Schlichting -
Jacob Holm -
Martijn Pieters -
Maurits van Rees -
Roger Ineichen -
Stephan Richter -
Wichert Akkerman