Following the threads on i18n for navigations, I'd just like to raise some points on the subject:
i18n can typically be achieved in 2 different fashions: - using different templates per locale (current Jetspeed way) - using a string lookup table/class to store locale dependant information (Turbine Localization service and tool). IMO, both solutions are targetted at different needs and should be used together to have a flexible, easy to maintain i18n system: - locale based templates should be used whenever a locale would require a different *layout* than the one used by the default locale-indepedent template. If the default is typically English, this can include Chinese, Hebrew, Japanese, etc.. - string lookup table should be used when the only differences between the locale screens are labels (typically the difference between English, French, Spanish, German, etc...) The main advantage of using string lookup tables is that you only have 1 template to maintain and don't need to propagate changes to all your locale-specific templates. Based, on these assumptions, I think we should somewhat rework how i18n is handled in Jetspeed and move to a string lookup table for the en, de, etc... examples. If someone in the community could provide alternate templates for any other locale that would require a different layout to be readable, it could serve to illustrate the proper use of locale specific templates. What do you think ? -- Rapha�l Luta - [EMAIL PROTECTED] Vivendi Universal Networks - Services Manager / Paris --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
