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 doubt either of those issues will slow development. I expect the
(relatively) most difficult part to be adding the transforming into
the Serializers. I used a pattern change for another Transformer; the
working code was moved to a static function, which is called by both
the standard entry point and another static function. Then the
Serializers can start with a call to the static entry point.
Development should take 1-3 days.
The downside is I have a full-time job, start college today (my
current position requires an MBA, and I never finished the BS), and am
still finishing the XML edit Module. There should only be 1 day of
work left to finish that Module, but I do not know when I will have
time.
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
