You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jetspeed-dev@portals.apache.org by ra...@networks.groupvu.com on 2001/10/14 11:17:44 UTC

i18n in Jetspeed

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 - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Services Manager / Paris


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: i18n in Jetspeed

Posted by ra...@networks.groupvu.com.
Paul Spencer wrote:
> Can both solutions be used at the same time?
> 

Sure. The default template would use string lookups for localized labels
while for some locales it would find some more specific templates and use
them instead...
--
Raphaël Luta - raphael.luta@networks.groupvu.com
Vivendi Universal Networks - Services Manager / Paris


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: i18n in Jetspeed

Posted by Paul Spencer <pa...@mikon.com>.
Can both solutions be used at the same time?

As an example, use a string lookup tables for the default navigation. 
This implementation would allow for a common navigation bar.  Many
languages with similar length text would share the common navigation
bar, and the remaining languages would have their own navigation bar.

Paul Spencer

raphael.luta@networks.groupvu.com wrote:
> 
> 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 - raphael.luta@networks.groupvu.com
> Vivendi Universal Networks - Services Manager / Paris
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: i18n in Jetspeed

Posted by Santiago Gala <sg...@hisitech.com>.
Jon Stevens wrote:

>on 10/14/01 2:17 AM, "raphael.luta@networks.groupvu.com"
><ra...@networks.groupvu.com> wrote:
>
>>Following the threads on i18n for navigations, I'd just like to raise some
>>points on the subject:
>>
>
>You got it 100% right raphael.
>
>+1
>
>Also, make sure to use Turbine's localization service. DLR just put a bunch
>of work into it because CollabNet is now using it. It is easy to use and
>works great. Scarab uses it as well.
>
FYI: I'm tracking turbine-2.2dev from cvs, and making sure it works with 
current Jetspeed. I've just updated a bunch of changes in 
TurbineLocalization. As soon as we have the TurbineResourceService with 
the following patch applied, Jetspeed will run again against cvs 
turbine-2, and we will be able to move forward with turbine-2.2dev.

cvs server: Diffing src/java/org/apache/turbine/services/resources
Index: 
src/java/org/apache/turbine/services/resources/TurbineResourceService.java
===================================================================
RCS file: 
/home/cvs/jakarta-turbine-2/src/java/org/apache/turbine/services/resources/TurbineResourceService.java,v
retrieving revision 1.4
diff -r1.4 TurbineResourceService.java
230a231,233
 >         //Get the full ResourceService (we could be in a subset instance)
 >         ResourceService top = TurbineResources.getService();
 >
243c246
<             if (configuration.get(variable)!=null)
---
 >             if (top.getString(variable)!=null)
245c248
<                 result.append(configuration.get(variable));
---
 >                 result.append(top.getString(variable));

The patch is needed because variable interpolation does not work when a 
TurbineServices.getResources(String subset) is requested, and we do this 
in the initialization of some services.

Jason has the patch, and he will apply it in the next days. Then we will 
enjoy the latest code in TurbineLocalization.

>
>
>-jon
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org
>




---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org


Re: i18n in Jetspeed

Posted by Jon Stevens <jo...@latchkey.com>.
on 10/14/01 2:17 AM, "raphael.luta@networks.groupvu.com"
<ra...@networks.groupvu.com> wrote:

> Following the threads on i18n for navigations, I'd just like to raise some
> points on the subject:

You got it 100% right raphael.

+1

Also, make sure to use Turbine's localization service. DLR just put a bunch
of work into it because CollabNet is now using it. It is easy to use and
works great. Scarab uses it as well.

-jon


---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: jetspeed-dev-help@jakarta.apache.org