[EMAIL PROTECTED] wrote:
> On 8/31/06, Joern Nettingsmeier <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> > On 8/29/06, Jörn Nettingsmeier <[EMAIL PROTECTED]> wrote:
>> >> [EMAIL PROTECTED] wrote:
>> >> > 1.3 tries to make translating completely transparent. I wanted to
>> >> > avoid aggregating the i18n catalogues, and also remove the need for
>> >> > the i18n Transformer in XMAPs, so i18n translation will be merged
>> into
>> >> > the Serializers. Each module translates as the document is passed
>> >> > around. No aggregation. No extra lines in the XMAPs. Each module
>> >> > can have its own i18n, and anything not translated passes up to the
>> >> > next level.
>> >> i had thought about this approach as well, in order to allow
>> modules to
>> >> introduce their own message keys and just localize those before the
>> >> content is handed back to the publication pipeline, but i could not
>> >> think of a way to do that without modifying the I18nTransformer.
>> >> iiuc, its default behaviour would have to be changed - currently it
>> >> either puts in the "untranslated" string or displays the i18n element
>> >> content. to accomodate your approach, it must leave those i18n tags
>> >> alone. the big downside is that this requires an extra clean-up step
>> >> before xhtml serializing, since any missing messages would otherwise
>> >> produce incorrect xhtml.
>> > Guess you skipped the required reading. Plans are to add a flag for
>> > handling unfound keys. The XMLSerializer leaves them alone. The
>> > HTMLSerializer changes them to "untranslated". Of course people
>> > could call the i18nTransformer directly if they need "untranslated" in
>> > their XML.
>> >> > This will incur some overhead, but it should be minimal, and more
>> than
>> >> > offset the issues of finding all the files and translation key
>> >> > collisions.
>> >> nice if it can be done.
>> >>
>> >> > I had not thought about the filenames, planning to stay
>> >> > backwards-compatible with 1.2. But I like the suggestion they could
>> >> > be named better. After almost a minute of thought, the files will
>> >> > probably be in an "i18n" subdirectory of each Module, and be named
>> >> > "en.xml", "de.xml", "ru.xml", etc. So the "live" module uses:
>> >> > {pub}/modules/live/i18n/en.xml
>> >> > {pub}/modules/live/i18n/de.xml
>> >> you will have to hack the I18nTranslator even more to do that.
>> >> currently, you pass it a catalogue basename like "foo", and if the
>> >> requested locale is "de_CH", it will try to locate first
>> foo_de_DE.xml,
>> >> then foo_de.xml and finally foo.xml. your scheme would mean an empty
>> >> basename...
>> > That sounds like another flag to bypass the catalogue resolution and
>> > use the new file structure. Programming is easy!
>>
>> i don't think it's wise to re-implement existing cocoon features with
>> totally different semantics. sounds like NIH syndrome to me. i'd rather
>> see the problem generalized and fed upstream, for instance with an extra
>> flag "leave untranslated tags as-is" in the i18ntransformer config.
>
> The concept is to add the new functionality reusing existing code
> without changing the old code's default usage. I would rather think
> it is the FSS/OSS ideal of everybody improving the code than NIH.
it's a transformer feature that could be useful for other cocoon
projects as well, so i think it belongs upstream. i don't buy the
"reuse, wrap up and tell nobody about it" concept of modern oop. if
something can (and should) be fixed upstream for the benefit of
everyone, it's wrong to just subclass it for your own private amusement!
this usage of subclassing is a clumsy workaround from the old world of
proprietary, binary-only libraries.
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).
with your design, you need an XMLGrandUnifiedSerializer and an
HTMLGrandUnifiedSerializer, and some day a TextGrandUnifiedSerializer...
i don't see the point.
--
"I don't need backups. I need restore!" - Trad.
--
Jörn Nettingsmeier, EDV-Administrator
Institut für Politikwissenschaft
Universität Duisburg-Essen, Standort Duisburg
Mail: [EMAIL PROTECTED], Telefon: 0203/379-2736
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
