You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Vincent van Beveren <vi...@nazarene.nl> on 2004/11/24 09:18:20 UTC

Localized data: best practice - insights appreciated

Hi everyone,

I have done some research, but found not much information that covers 
this topic.

Suppose I have an object (JavaBean) with localized data. For example a 
Product that for each supported language contains a title and a 
description. Now suppose I want to display this data using Velocity in 
his/her language, what would be good practice? How would I set up the 
Java objects, and how would I show the information in Velocity? 
Insights, and experience appreciated.

Thanks in advance,
Vincent


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


Re: Localized data: best practice - insights appreciated

Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Vincent,

> In my case information is loaded from a database.

That shouldn't stop you from making a DatabaseResourceBundle.  B)

> The thing I'm
> considering is that it would be easiest to access the information in a
> property kind of way, like normal Velocity code:
> 
>    $product.title
> 
> but this would infact invoke:
> 
>    String product.getTitle(usersLocale);
> 
> or something of the sort. This would be how I would attempt to do it.

If you make a POJO with the method get(String property), it will be
called.  ie. $product.title will invoke product.get("title"). 
(assuming that product is what is in $product.)  Now, all you have to
do is go ahead and make it.  ;)

> I'm sure other people have struggled with the same problem, and I wish
> to know what their solution would be. Anyone has attempted to do the same?

Of course, I've only worked with one-language applications, so it
might not be the best practice.
## I do have a link inside me from i18n to ResourceBundle, though.

Best regards,
-- Shinobu Kawai

-- 
Shinobu Kawai <sh...@gmail.com>

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


Re: Localized data: best practice - insights appreciated

Posted by Claude Brisson <cl...@renegat.net>.
Hi

On Wed, 2004-11-24 at 17:35, Simon Christian wrote:

> I don't know is this would count as a 'best practice', but how about 
> using a ThreadLocal on each request to hold the Locale of the visitor. 
> Then the Product (for instance) would be able to find the Locale all by 
> itself and return the appropriate String.
> 
> I notched up a little example doing this using a Servlet Filter to 
> capture and store the Locale (which I hope doesn't line-wrap too badly):

[...]

> You should then be able to access the Locale by just calling 
> LocaleFilter.getLocale() from within the Product or elsewhere.

'elsewhere' can be a custom ReferenceInsertionHandler (see
http://jakarta.apache.org/velocity/developer-guide.html#EventCartridge%20and%20Event%20Handlers). If the methods Product.getTitle() and co. return ids as an identifiable string, like "locid_1234", or -much better- as a specific class, your handler can convert such strings on the fly :

1. Velocity renderer encounters $product.title

2. Product.getTitle() returns LocalizedString(1234) (where
LocalizedString is just a wrapper around an ID)

3. your LocalizationHandler watches for LocalizedString and uses the
LocaleFilter.getLocale() and the DB to find the appropriate String (or
delegates all this stuff to a Localizer via a static method
getString(LocalizedString,Locale)) and returns it to the renderer.

Just an idea, hope I made it clear...

Claude



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


Re: Localized data: best practice - insights appreciated

Posted by Simon Christian <si...@stoutstick.com>.
Hi Vincent,

Vincent van Beveren wrote:
>>
> In my case information is loaded from a database. The thing I'm 
> considering is that it would be easiest to access the information in a 
> property kind of way, like normal Velocity code:
> 
>    $product.title
> 
> but this would infact invoke:
>      String product.getTitle(usersLocale);
> 
> or something of the sort. This would be how I would attempt to do it. 
> Ofcourse I could also build a tool, like the 'localeTool' and do the 
> following:
> 
>    $localeTool.getMessage($product.title)
> 
> where $product.title would return some object that contains a string for 
> each locale, and LocaleTool would know how to extract the right string 
> from the bunch. But I find this rather verbose, and it makes the code ugly.
> 
> The lost solution is ofcourse to store the locale in the model and do 
> the follow:
> 
>    $product.getTitle($locale)
> 
> But I'm not content with that either, since I'm rather a purist in 
> seperation of code and view.
> 
> I'm sure other people have struggled with the same problem, and I wish 
> to know what their solution would be. Anyone has attempted to do the same?
> 

I don't know is this would count as a 'best practice', but how about 
using a ThreadLocal on each request to hold the Locale of the visitor. 
Then the Product (for instance) would be able to find the Locale all by 
itself and return the appropriate String.

I notched up a little example doing this using a Servlet Filter to 
capture and store the Locale (which I hope doesn't line-wrap too badly):

------------------------------------------------------------------
import java.io.IOException;

import java.util.Locale;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;

/**
  * Filter which holds a ThreadLocal with the Locale
  * of the current request
  *
  * @author <a href="mailto:simon@stoutstick.com">Simon Christian</a>
  */
public class LocaleFilter implements Filter
{
     /**
      * Holds the current request's Locale
      */
     protected static ThreadLocal localeHolder = new ThreadLocal();

     /**
      * No init required
      */
     public void init(FilterConfig filterConfig) throws ServletException
     {
     }

     /**
      * Set the locale as specified by the request
      */
     public void doFilter(ServletRequest request,
	ServletResponse response, FilterChain chain)
         	throws IOException, ServletException
     {

         localeHolder.set( request.getLocale() );

         chain.doFilter( request, response );
     }

     /**
      * Return the Locale as held on the ThreadLocal
      */
     public static Locale getLocale()
     {
         return (Locale)localeHolder.get();
     }

     /**
      * Nothing to destroy
      */
     public void destroy()
     {
     }
}
------------------------------------------------------------------

You should then be able to access the Locale by just calling 
LocaleFilter.getLocale() from within the Product or elsewhere.

hth,

- simon



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


Re: Localized data: best practice - insights appreciated

Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Vincent,

> In my case $msg.get would have to request the message from the database
> on the basis of the message. Suppose (which is not at all unlikely in my
> situation) that we're talking about a database with 250.000 products.
> Each product has mutliple internationalized texts (description, title,
> etc...) , even with only two messages per product this would result in
> 500.000 entries. It would not be convinient to create a code to message
> mapping. Showing just a list of search results would be an huge strain
> on the database. The objects themselves would need to know their
> messages in different languages, that would be more convinient.

All the localized text is in the database, right?  How about getting
the localized text prior to setting it in the Context?

Best regards,
-- Shinobu Kawai

-- 
Shinobu Kawai <sh...@gmail.com>

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


Re: Localized data: best practice - insights appreciated

Posted by Vincent van Beveren <vi...@nazarene.nl>.
Hi Mike,

Mike Kienenberger wrote:

>Vincent van Beveren <vi...@nazarene.nl> wrote:
>  
>
>>Ofcourse I could also build a tool, like the 'localeTool' and do the 
>>following:
>>
>>    $localeTool.getMessage($product.title)
>>
>>where $product.title would return some object that contains a string for 
>>each locale, and LocaleTool would know how to extract the right string 
>>from the bunch. But I find this rather verbose, and it makes the code 
>>    
>>
>ugly.
>
>$msg.get($product.title) isn't all that verbose, to use the struts version.
>  
>
In my case $msg.get would have to request the message from the database 
on the basis of the message. Suppose (which is not at all unlikely in my 
situation) that we're talking about a database with 250.000 products. 
Each product has mutliple internationalized texts (description, title, 
etc...) , even with only two messages per product this would result in 
500.000 entries. It would not be convinient to create a code to message 
mapping. Showing just a list of search results would be an huge strain 
on the database. The objects themselves would need to know their 
messages in different languages, that would be more convinient.

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


Re: Localized data: best practice - insights appreciated

Posted by Mike Kienenberger <mk...@alaska.net>.
Vincent van Beveren <vi...@nazarene.nl> wrote:
> Ofcourse I could also build a tool, like the 'localeTool' and do the 
> following:
> 
>     $localeTool.getMessage($product.title)
> 
> where $product.title would return some object that contains a string for 
> each locale, and LocaleTool would know how to extract the right string 
> from the bunch. But I find this rather verbose, and it makes the code 
ugly.

$msg.get($product.title) isn't all that verbose, to use the struts version.

Unless you're going to build localization into every single object, you're 
going to need something of that form anyway -- A key that says what you want 
to localize, and a tool to do the localization.


> In my case information is loaded from a database.

That's just a hidden implementation detail, and not really part of the 
problem definition.
I also load my info from a database, but it looks the same in velocity.



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


Re: Localized data: best practice - insights appreciated

Posted by Vincent van Beveren <vi...@nazarene.nl>.
Hi Shinobu,

>Have you looked at ResourceBundles?
>  http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html
>
>It shouldn't be too hard to make a ViewTool for it using
>ServletRequest#getLocale().
>  http://jakarta.apache.org/velocity/tools/view/
>  http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#getLocale()
>
>## Or does one exist already?
>
>Best regards,
>-- Shinobu Kawai
>  
>
In my case information is loaded from a database. The thing I'm 
considering is that it would be easiest to access the information in a 
property kind of way, like normal Velocity code:

    $product.title

but this would infact invoke:
   
    String product.getTitle(usersLocale);

or something of the sort. This would be how I would attempt to do it. 
Ofcourse I could also build a tool, like the 'localeTool' and do the 
following:

    $localeTool.getMessage($product.title)

where $product.title would return some object that contains a string for 
each locale, and LocaleTool would know how to extract the right string 
from the bunch. But I find this rather verbose, and it makes the code ugly.

The lost solution is ofcourse to store the locale in the model and do 
the follow:

    $product.getTitle($locale)

But I'm not content with that either, since I'm rather a purist in 
seperation of code and view.

I'm sure other people have struggled with the same problem, and I wish 
to know what their solution would be. Anyone has attempted to do the same?

Thanks,
Vincent







-- 
XIAM Solutions B.V.
Barchman Wuytierslaan 72A
3818 LK AMERSFOORT
tel. : +31(0)33 462 40 07
e-mail: vincent@nazarene.nl, info@xiam.nl

WAARSCHUWING:
Dit bericht is UITSLUITEND bestemd voor de (rechts)perso(o)n(en) aan welke het bericht is gericht. Het kan vertrouwelijke of alleen voor deze rechts)perso(o)n(en) bestemde informatie bevatten, die niet mag worden geopenbaard. Als dit bericht niet voor u bestemd is, mag u de ontvangen informatie niet lezen, gebruiken, verspreiden of kopiƫren. Als u dit bericht per abuis heeft ontvangen, gelieve het bericht dan te vernietigen en contact op te nemen met de afzender.

WARNING:
This message is intended ONLY for the person(s) or entity to which it is addressed and may contain confidential and/or privileged information, the disclosure of which is prohibited. If you are not the intended recipient you may not read, use, disseminate or copy the information transmitted. If you have received this message by mistake, please contact the sender and delete the material from any computer.


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


Re: Localized data: best practice - insights appreciated

Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Vincent,

> Suppose I have an object (JavaBean) with localized data. For example a
> Product that for each supported language contains a title and a
> description. Now suppose I want to display this data using Velocity in
> his/her language, what would be good practice? How would I set up the
> Java objects, and how would I show the information in Velocity?
> Insights, and experience appreciated.

Have you looked at ResourceBundles?
  http://java.sun.com/j2se/1.5.0/docs/api/java/util/ResourceBundle.html

It shouldn't be too hard to make a ViewTool for it using
ServletRequest#getLocale().
  http://jakarta.apache.org/velocity/tools/view/
  http://java.sun.com/j2ee/1.4/docs/api/javax/servlet/ServletRequest.html#getLocale()

## Or does one exist already?

Best regards,
-- Shinobu Kawai

-- 
Shinobu Kawai <sh...@gmail.com>

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


Re: Localized data: best practice - insights appreciated

Posted by Shinobu Kawai <sh...@gmail.com>.
Hi Vincent,

> Suppose I have an object (JavaBean) with localized data. For example a
> Product that for each supported language contains a title and a
> description. Now suppose I want to display this data using Velocity in
> his/her language, what would be good practice? How would I set up the
> Java objects, and how would I show the information in Velocity?
> Insights, and experience appreciated.

This site should help you with design concepts in i18n and l10n apps:
  J2EE Internationalization and Localization
  http://java.sun.com/blueprints/guidelines/designing_enterprise_applications_2e/i18n/i18n.html

Best regards,
-- Shinobu Kawai

-- 
Shinobu Kawai <sh...@gmail.com>

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