On 8/31/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
Joern Nettingsmeier wrote:
> btw, i'm not convinced about unifying the i18ntransformer and the
> serialization. why should this be done? it saves a few lines of sitemap
> code at the cost of even more implicit magic that will be non-obvious to
> people not familiar with lenya extensions. and from a design pov, i
> think it's a step backwards to lump orthogonal stuff together.
> serializing has a special meaning as the final stage of a pipeline that
> "returns" a full xml tree or other "final" rendition. i18n is just
> another transformer (which is nice imho).
I agree to this. Replacing something in a SAX stream is a transformer
task.
The HTML Serializer replaces <BR/> with <BR>. It should remove empty
<I/> (italics) elements. There are probably other replacements. Its
job is to transform the stream into HTML. <i18n:text> is not an HTML
tag. Yes, it requires more code than the current changes, but
replacing i18n tags is still within its function.
Adding i18n transformation to the XMLSerializer is more difficult to
justify. i18n elements are obviously XML. But almost every XMAP
Pipeline in Lenya should end with:
<map:transform type="i18n">
<map:parameter name="locale" value="{page-envelope:document-language}"/>
</map:transform>
<map:serialize/>
Merging the functions saves 3 lines per pipeline. Another advantage
of merging them is translation becomes part of the Lenya platform
rather than something a developer needs to consider.
Many of the changes in 1.3 are designed specifically to make that
possible. Language translation is one of the easier functions to move
into core Lenya. A call to 1.3's SitetreeTransformer returns just the
current language, greatly simplifying the XSL for creating
NavigationElements. The content: protocol defaults to the current
language; that is one more thing developers can ignore. There are
ways to override the default functionality, but each improvement in
the platform reduces the code, and the experience needed to develop
Lenya applications.
Joern states this functionality would be non-obvious to the casual
developer. That is fine. That is the point. A casual developer would
benefit the most from not needing to remember to explicitly handle
i18n. If the functionality is unwanted, they can learn how to disable
it, which will be as easy as adding a parameter.
My goal is to make Lenya as simple and flexible as possible. Merging
i18n into the Serializers makes it simpler. Allowing the
functionality to be disabled makes it flexible.
---
Another advantage is this provides an easy method to handle
Module-specific translation. Building catalogues from multiple files
scattered in many Modules is not necessary. Did you record which
Modules were used for the current process, so only translations from
those Modules are used? There are no issues with duplicate keys. The
same key can be used by every Module, the elements are replaced before
leaving the Module (without developer effort), and the results are
what is expected.
The fundamental requirement is to handle i18n before leaving each
Module. The only function guaranteed to be in every pipeline is a
Serializer. The solution seemed obvious.
If anyone can think of a different method to accomplish all this, I
would love to hear it.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
