Re: [Zope-CMF] i18n for CMF And Plone, backporting i18n to Zope 2.x
Hi Robert, My friend Lalo (lalo@laranja.org) started a rewrite of TAL to make it more pluggable and ease backporting of i18n to Zope2. I dont know how much if it is done right now, but the last time I talked to him, he said that only METAL was missing. His work is available at http://sf.net/projects/collective -> Browse CVS -> Alt-TAL module. I think that the best idea is support him, as he has almost everything in place. []'s On Seg 01 Jul 2002 11:50, Robert Rottermann wrote: | Hi Zopistas, | | I would very much appreciate your ideas and support in the matter of | backporting Z3 i18n support to 2.6+ | | I did get a number of answers to my inquiry regarding i18n support for | Plone. | It seems that the only sensible way to do this, is to backport the i18n | support from Zope3's TAL to Zope2.'s TAL. | | I have been looking into Zope3's TAL. What I found created mixed | enthusiasm. | | - there seems not to much code in TAL itself that is i18n related. | - However the TAL3's structure has been altered somehow to reflect changes | in Zope3's structure. | | Since I have not dealt much with Zope3 yet I have no idea what is needed to | add a module in TAL 2.6+ that | adds functionality to deal with such tags: | | (This are a snippets from Plone templates.) | ------------- | <span i18n:translate="">Posted by:</span> | <span tal:content="here/Creator">Poster Name</span> | <span i18n:translate="">at</span> | <span tal:replace="python: here.toPortalTime(here.modified())">8/23/2001 | 12:40:44 PM</span> | ------------- | <p tal:condition="not: len_text" | i18n:id="no_body_text"> | This document has yet to be written, click the edit tab to change the | document. | </p> | ------------- | | One could maybe use a brute force approach and just add a filter after the | TAL processing that deals with all i18n artifacts it finds. | | thanks for your input | | mit freundlichen Grüssen | | Robert Rottermann | | Wir wollen Technik mit Menschlichkeit verbinden, | um Menschen mit Technik zu erreichen. | www.redcor.ch - die website | www.redcor.net - zope trainings (and more) | | | | _______________________________________________ | Zope-CMF maillist - Zope-CMF@zope.org | http://lists.zope.org/mailman/listinfo/zope-cmf | | See http://www.zope.org/Products/PTK/Tracker for bug reports and feature | requests -- Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18-newpmac ppc I wish you humans would leave me alone.
Stephan Richter and Zope Corp are porting Zope 3 ZPT I18n support to Zope 2.x, probably with a target of Zope 2.7. Jim Sidnei da Silva wrote:
Hi Robert,
My friend Lalo (lalo@laranja.org) started a rewrite of TAL to make it more pluggable and ease backporting of i18n to Zope2. I dont know how much if it is done right now, but the last time I talked to him, he said that only METAL was missing.
His work is available at http://sf.net/projects/collective -> Browse CVS -> Alt-TAL module.
I think that the best idea is support him, as he has almost everything in place.
[]'s
On Seg 01 Jul 2002 11:50, Robert Rottermann wrote: | Hi Zopistas, | | I would very much appreciate your ideas and support in the matter of | backporting Z3 i18n support to 2.6+ | | I did get a number of answers to my inquiry regarding i18n support for | Plone. | It seems that the only sensible way to do this, is to backport the i18n | support from Zope3's TAL to Zope2.'s TAL. | | I have been looking into Zope3's TAL. What I found created mixed | enthusiasm. | | - there seems not to much code in TAL itself that is i18n related. | - However the TAL3's structure has been altered somehow to reflect changes | in Zope3's structure. | | Since I have not dealt much with Zope3 yet I have no idea what is needed to | add a module in TAL 2.6+ that | adds functionality to deal with such tags: | | (This are a snippets from Plone templates.) | ------------- | <span i18n:translate="">Posted by:</span> | <span tal:content="here/Creator">Poster Name</span> | <span i18n:translate="">at</span> | <span tal:replace="python: here.toPortalTime(here.modified())">8/23/2001 | 12:40:44 PM</span> | ------------- | <p tal:condition="not: len_text" | i18n:id="no_body_text"> | This document has yet to be written, click the edit tab to change the | document. | </p> | ------------- | | One could maybe use a brute force approach and just add a filter after the | TAL processing that deals with all i18n artifacts it finds. | | thanks for your input | | mit freundlichen Grüssen | | Robert Rottermann | | Wir wollen Technik mit Menschlichkeit verbinden, | um Menschen mit Technik zu erreichen. | www.redcor.ch - die website | www.redcor.net - zope trainings (and more) | | | | _______________________________________________ | Zope-CMF maillist - Zope-CMF@zope.org | http://lists.zope.org/mailman/listinfo/zope-cmf | | See http://www.zope.org/Products/PTK/Tracker for bug reports and feature | requests
-- -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
"SdS" == Sidnei da Silva <sidnei@x3ng.com.br> writes:
SdS> My friend Lalo (lalo@laranja.org) started a rewrite of TAL to SdS> make it more pluggable and ease backporting of i18n to SdS> Zope2. I dont know how much if it is done right now, but the SdS> last time I talked to him, he said that only METAL was SdS> missing. SdS> His work is available at http://sf.net/projects/collective -> SdS> Browse CVS -> Alt-TAL module. SdS> I think that the best idea is support him, as he has almost SdS> everything in place. A quick scan didn't show much i18n support there, but perhaps I'm missing it. FTR, Stephan demoed the Zope3 i18n stuff at EuroPython and we're planning on backporting it to Zope2, but for the Zope 2.7 release. -Barry
Well, i didnt told there was i18n support there ;) Basically, Alt-TAL is a rewrite of TAL to allow one to expand TAL by providing plugins. This means that if you want to provide i18n for Alt-TAL you just need to write an i18n plugin and register it as a handler for i18n:something. The the current TAL implementation is very obscure, and Shane agrees with us that it could be highly improved with no much effort. At a first glance, you can see that this implementation is much clear, and pluggable, and the current TAL needs too much hacking to extend support for new tags, and has too much dependencies on Zope right now, as someone pointed out. Im forwarding this thread to zope-dev so we can disscuss this there. I hope Lalo can get online soon and explain his ideas, as i havent participated on this rewrite at all. Jim also said that I should talk with Fred Drake, as he is the guy at PythonLabs that is in charge of TAL, so im forwarding this to him too. []'s On Seg 01 Jul 2002 13:48, Barry A. Warsaw wrote: | >>>>> "SdS" == Sidnei da Silva <sidnei@x3ng.com.br> writes: | | SdS> My friend Lalo (lalo@laranja.org) started a rewrite of TAL to | SdS> make it more pluggable and ease backporting of i18n to | SdS> Zope2. I dont know how much if it is done right now, but the | SdS> last time I talked to him, he said that only METAL was | SdS> missing. | | SdS> His work is available at http://sf.net/projects/collective -> | SdS> Browse CVS -> Alt-TAL module. | | SdS> I think that the best idea is support him, as he has almost | SdS> everything in place. | | A quick scan didn't show much i18n support there, but perhaps I'm | missing it. | | FTR, Stephan demoed the Zope3 i18n stuff at EuroPython and we're | planning on backporting it to Zope2, but for the Zope 2.7 release. | | -Barry -- Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18-newpmac ppc All the existing 2.0.x kernels are to buggy for 2.1.x to be the main goal. -- Alan Cox
"SdS" == Sidnei da Silva <sidnei@x3ng.com.br> writes:
SdS> Well, i didnt told there was i18n support there ;) Oh! :) SdS> Basically, Alt-TAL is a rewrite of TAL to allow one to expand SdS> TAL by providing plugins. This means that if you want to SdS> provide i18n for Alt-TAL you just need to write an i18n SdS> plugin and register it as a handler for i18n:something. The SdS> the current TAL implementation is very obscure, and Shane SdS> agrees with us that it could be highly improved with no much SdS> effort. SdS> At a first glance, you can see that this implementation is SdS> much clear, and pluggable, and the current TAL needs too much SdS> hacking to extend support for new tags, and has too much SdS> dependencies on Zope right now, as someone pointed out. I don't know about the "not much effort" part, but in theory, this is something I'd support. We talked about doing this for the Zope3 i18n effort, but the primary reason we didn't was due to performance concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML. So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will "perform adequately"? -Barry
Barry A. Warsaw writes:
concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML.
Well, faster than it used to. We need to spend time on performance.
So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will "perform adequately"?
It might be time to investigate Pyrex: http://www.cosc.canterbury.ac.nz/~greg/python/Pyrex/ -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation
Hi!
Barry A. Warsaw writes:
concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML.
Well, faster than it used to. We need to spend time on performance.
Indeed. All my "pseudo-benchmarking" resulted in ZPT being up to 4 times slower than DTML ... Wouldn't it possible to precompile ZPT into Python bytecode or even something more efficient? We've compared DTML and ZPT to working with Python strings that get variables passed, and the later was way faster. Which is more or less obvious as it does not do nearly the same DTML/ZPT do (i.e. security checks and the like) ... I'd probably be happy with some way of creating pseudo-dynamic templates that only have dynamic "hot spots", like server side includes in Apache, but use precompiled or cached version of the template for the rest. The problem is that most of the time we could use Zope + a cacheing proxy, except for very small parts of the page that make it uncacheable as a whole ...
So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will "perform adequately"?
It might be time to investigate Pyrex:
This one sounds good ... Joachim
Barry A. Warsaw wrote:
"SdS" == Sidnei da Silva <sidnei@x3ng.com.br> writes:
SdS> Well, i didnt told there was i18n support there ;)
Oh! :)
SdS> Basically, Alt-TAL is a rewrite of TAL to allow one to expand SdS> TAL by providing plugins. This means that if you want to SdS> provide i18n for Alt-TAL you just need to write an i18n SdS> plugin and register it as a handler for i18n:something. The SdS> the current TAL implementation is very obscure, and Shane SdS> agrees with us that it could be highly improved with no much SdS> effort.
SdS> At a first glance, you can see that this implementation is SdS> much clear, and pluggable, and the current TAL needs too much SdS> hacking to extend support for new tags, and has too much SdS> dependencies on Zope right now, as someone pointed out.
I don't know about the "not much effort" part, but in theory, this is something I'd support. We talked about doing this for the Zope3 i18n effort, but the primary reason we didn't was due to performance concerns. After talking with Fred, I came to understand that much of the code's current obscurity is due to optimizations to make TAL perform at least as fast as DTML.
So while I'd love to have the code be cleaner and more pluggable, we have to decide 1) if we're willing to give up some performance to acheive this, and 2) if not, can you provide a design and implementation that will "perform adequately"?
I'll add that the current ZPT implementation is too slow (thanks to recent DTML speedups ;). ZPT needs to be as fast as or faster than DTML. It would be great if it was cleaner and more pluggable. Jim -- -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Seg 01 Jul 2002 15:26, Jim Fulton wrote: | I'll add that the current ZPT implementation is too slow | (thanks to recent DTML speedups ;). | | ZPT needs to be as fast as or faster than DTML. It would be | great if it was cleaner and more pluggable. | | Jim I remember that i had the same concern when discussing this with lalo, and he told me that this should be faster, as TAL-Current stores a binary representation of the XML Parsed source, and his version is based on PAX, and this would not need to be pre-compiled and stored. Unfortunately I cannot give more information as this explanation seemed fine to me at that time. []'s -- Sidnei da Silva (dreamcatcher) <sidnei@x3ng.com.br> X3ng Web Technology <http://www.x3ng.com.br> GNU/Linux user 257852 Debian GNU/Linux 3.0 (Sid) 2.4.18-newpmac ppc FORTRAN rots the brain. -- John McQuillin
Sidnei da Silva wrote:
On Seg 01 Jul 2002 15:26, Jim Fulton wrote: | I'll add that the current ZPT implementation is too slow | (thanks to recent DTML speedups ;). | | ZPT needs to be as fast as or faster than DTML. It would be | great if it was cleaner and more pluggable. | | Jim
I remember that i had the same concern when discussing this with lalo, and he told me that this should be faster, as TAL-Current stores a binary representation of the XML Parsed source, and his version is based on PAX, and this would not need to be pre-compiled and stored. Unfortunately I cannot give more information as this explanation seemed fine to me at that time.
I'm far less concerned with parsing speed than with execution speed. I find it hard to believe that an implementation that parses every time a page is rendered will be faster than an implementation that renders from a compiled form. Jim -- -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (888) 344-4332 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Mon, Jul 01, 2002 at 03:49:07PM -0300, Sidnei da Silva wrote:
On Seg 01 Jul 2002 15:26, Jim Fulton wrote: | I'll add that the current ZPT implementation is too slow | (thanks to recent DTML speedups ;). | | ZPT needs to be as fast as or faster than DTML. It would be | great if it was cleaner and more pluggable.
I remember that i had the same concern when discussing this with lalo, and he told me that this should be faster, as TAL-Current stores a binary representation of the XML Parsed source, and his version is based on PAX, and this would not need to be pre-compiled and stored. Unfortunately I cannot give more information as this explanation seemed fine to me at that time.
Our original prototypes of ZPT stored a DOM tree in the ZODB, so they only really parsed the source when it was updated. When the stuff was rewritten for optimization, DOM was done away with in favour of TAL "bytecode" which, for some reason, isn't stored persistently. I asked once, and I seem to remember the answer was "it doesn't pickle well". Well, Alt-TAL is an experiment to see how fast a pluggable and readable version of TAL could be. My first step was to construct a "bytecode" that is pickleable and is not TAL-specific. This is PAX. I didn't yet announce PAX anywhere as it is evolving fast to meet the needs of Alt-TAL, but I plan to make it a package in its own right in the near future. In Alt-TAL, rendering TAL is a "PAX Transform". This dawned on me as a result of a comment by Leo Almeida that TAL could probably be implemented as a XSLT sheet. Alt-TAL currently only implements the tal: namespace, and tal:on-error is missing because it implies an exception-handling infrastructure which I didn't yet even design. So, the reason I didn't announce Alt-TAL was that it was so incomplete. But in my tests (and I run tests on a very old ppc machine, so that I may get a visual feel for the speed differences), the few input templates that already pass, pass faster than with the original TAL. Of course this experience has a long way to go. I need tal:on-error, then all metal: stuff, then make a version of PageTemplate that uses Alt-TAL (originally I planned Alt-TAL to be a drop-in replacement, but that would impact performance very badly so I gave up), then benchmark and optimize and benchmark and rinse and repeat. In a very extreme case, PAX (or perhaps PAX transform) can be optimized into C or Pyrex. As it has a lot of "for" loops, I assume this would be a gain. Of course, as my design skills are stronger than my coding skills, and as my optimizing skills are very very weak [;-)], I invite anyone interested in this experience to join in. []s, |alo +---- -- It doesn't bother me that people say things like "you'll never get anywhere with this attitude". In a few decades, it will make a good paragraph in my biography. You know, for a laugh. -- http://www.laranja.org/ mailto:lalo@laranja.org pgp key: http://www.laranja.org/pessoal/pgp Eu jogo RPG! (I play RPG) http://www.eujogorpg.com.br/ Python Foundry Guide http://www.sf.net/foundry/python-foundry/
participants (6)
-
barry＠zope.com -
Fred L. Drake, Jr. -
Jim Fulton -
Joachim Werner -
Lalo Martins -
Sidnei da Silva