[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.
--
"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]
