portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ingo schuster <ingo.apa...@web.de>
Subject Re: NLS in Jetspeed
Date Thu, 08 Mar 2001 17:03:10 GMT
Ok Santiago, sorry for answering so late - I had problems with my mailing...

I checked in a first version of the MLS code. Some German pages are 
provided as demonstration.
What I changed:
* The Jetspeed SessionValidator determines the user locale (browser 
settings or default defined in TR.p) and stores it in the user's TempStore 
as "locale" .
* I copied the TurbineTemplateService to JetspeedTemplateService - the only 
method that has changed is "parseScreenTemplate", but I didn't manage to 
subclass the TurbineService in a simple way - too many "privates" (Will 
discuss this on the turbine list).
The service now does a fallback strategy when it can't find a template. 
This was already done for layouts, but not for screens... To give an example:
A template name "/html/en/US/IE/mytemplate" would result in a search for 
following files (in the given order):
  1. /html/en/US/IE/mytemplate
  2. /html/en/US/mytemplate
  3. /html/en/mytemplate
  4. /html/mytemplate
  5. /mytemplate
* I modified JetspeedTemplatePage and JetspeedJspLayout to work with the 
new code (minor changes).

So this code can be used for NLS (the porlets don't care about the user's 
locale at the moment!). However (Santiago), the fallback is hardcoded in 
the JetspeedTemplatePage, it's "<type>/<languange>/<country>". I see the

beauty of your suggestion, but as I'm pretty satisfied with this, it'll 
take some time until I add configurability (unless somebody else implements 
is sooner ;-).
Unifying the code in a new Service is probably a good idea, but I haven't 
spend any thoughts on this yet.


At 19:36 02/28/01, Santiago Gala wrote:
>ingo schuster escribió:
> >
> > I'd like to improve the national language support in Jetspeed. The idea is
> > pretty simple:
> >
> > * We write a set of templates for each language.
> > * The templates are moved into respective subdirectories (e.g.
> > templates/jsp/en/{layouts,navigations,screens} for JSP templating and
> > english language).
> > * The JetspeedSesionValidator adds the language to the user's TempStore.
> > This could be the user agent's preferred language and as a fallback the
> > locale.default.language setting in TR.p.
> > * The template system is modified to use the user.getTemp("locale") for
> > searching the templates in the respective subdirectory (I think subclassing
> > the TurbineTemplateService is the easiest way of doing this). We can have a
> > set of default templates that'll be choosen if the language specific
> > template directories don't contain the requested template. (E.g.  for the
> > Ecs screen template, as this it 100% language independent)
> >
> > Comments, want me to develop this (Shouldn't take too long ;-))?
> >
>We have similar code. Also, the Profiler has this code for retrieving
>the psml.
>We should possibly unify this code (there are already comments in
>Profiler pointing
>to the use of language to select psml).
>Also, don't forget it is lang_COUNTRY, as in de, de_AT, de_CH, de_DE
>(jre even has a de_DE_EURO).
>I think the approach should be having
>(files here)
>     lang
>     (files here maybe)
>         COUNTRY
>         (files here maybe)
>The schema for psml is user/mime_type or group/mime_type or
>Our schema for skins is lang/mime_type/browser/version/theme
>I think we should unify this code under the Profiler Service, to have a
>method that,
>given a CapabilityMap/RunData, a "kind_of_resource" and a name, returns
>the resource going to
>the leaves and falling back if it does not exist.
>We could have configurable variations on resources, like:
>And the code would call getCountry (a la bean) and use the returned
>property to do the search,
>using the ordering of the variations to do a depth first search with
>This last idea is highly speculative, maybe it is better to have
>Profiles for different variations of the idea.
>(You asked for comments, so don't protest now :-)
>To subscribe:        jetspeed-on@list.working-dogs.com
>To unsubscribe:      jetspeed-off@list.working-dogs.com
>Search: <http://www.mail-archive.com/jetspeed@list.working-dogs.com/>
>List Help?:          jon@working-dogs.com

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

View raw message