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.
public class i18nTransformer...
protected org.w3c.dom.Document transform(org.w3c.dom.Document doc){
return doTransform(DEFAULT OPTIONS);
}
static public org.w3c.dom.Document transformDocument(ALL PARAMETERS){
return doTransform(ALL PARAMETERS);
}
static private org.w3c.dom.Document doTransform(ALL PARAMETERS){
//All processing code
}
}
- The class is revised so all i18n code is kept together.
- Using the i18nTransformer in an XMAP still does exactly the
backwards-compatible expected functionality.
- The Serializers can call the static function with options for the
new functionality.
- Parameters can be added to the XMAP version later if that is desirable.
- We pass working code upstream rather than asking the Cocoon
developers to please add the functionality and expecting them to do
the work.
We can rename the Serializers to avoid conflicts:
XMLSerializerWithi18n
HTMLSerializerWithi18n
and configure Lenya to use them. Again, the best design is to
slightly modify the existing classes so the functionality can be
called by the new classes:
public class XMLSerializerWithi18n
public void setOutputStream(OutputStream out)
doc = i18nTransformer.transformDocument(DO NOT TRANSLATE IF KEY
NOT FOUND);
return XMLSerializer.doSerialize(doc);
}
}
If someone will just fill in the blanks, the code will be done.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
