Localization on the fly

View: New views
8 Messages — Rating Filter:   Alert me  

Localization on the fly

by mike.r.phillips :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Can woodstock localization be based on the users current browser language choice(request.getLocale())?

After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
I can only get the correct localized strings and buttons used by the underlying components to be used if I add
a JVM option "-Duser.language=de" to the app server, or if I use Locale.setDefault(choosenLocale) and then
re-deploy my app.

if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create that are not part of
underlying components are localized correctly and change for each user base on browser preference.

Is there a way to tell components to reload the localized strings without bouncing app server?

Re: Localization on the fly

by richard ratta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

What version of woodstock are you using ?

The last I remember is that the locale IS determined based on browser
locale and
you should not have to do anything else to see this.

Now the gotcha...

Depending on which version of woodstock you are using you have to
make sure that the javascript theme also reflects the localizations you
are setting
in "messages_de.properties.".

In the later versions of woodstock, especially for components that have
widget renderers, the javascript theme must have all the localizations
that exist
in properties files. This is accomplished in the build of the "theme".

See

http://webdev2.sun.com/woodstock-theme-doc/index.html#toc

for more information on this topic.

-rick

mike.r.phillips wrote:

>Can woodstock localization be based on the users current browser language
>choice(request.getLocale())?
>
>After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
>I can only get the correct localized strings and buttons used by the
>underlying components to be used if I add
>a JVM option "-Duser.language=de" to the app server, or if I use
>Locale.setDefault(choosenLocale) and then
>re-deploy my app.
>
>if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create
>that are not part of
>underlying components are localized correctly and change for each user base
>on browser preference.
>
>Is there a way to tell components to reload the localized strings without
>bouncing app server?
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: Localization on the fly

by mike.r.phillips :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

We are using the version of woodstock that comes in netbeans 5.5.

I just ran a test on netbeans 6.1 and you are correct the localization is controlled by browser locale just the way
I would like.

Problem is we couldn't switch to new netbeans and woodstock because performance was so poor. Is there
a way to get this localization behavior from the woodstock that comes with 5.5

Is there a way to list out the woodstock version?

richard ratta wrote:
What version of woodstock are you using ?

The last I remember is that the locale IS determined based on browser
locale and
you should not have to do anything else to see this.

Now the gotcha...

Depending on which version of woodstock you are using you have to
make sure that the javascript theme also reflects the localizations you
are setting
in "messages_de.properties.".

In the later versions of woodstock, especially for components that have
widget renderers, the javascript theme must have all the localizations
that exist
in properties files. This is accomplished in the build of the "theme".

See

http://webdev2.sun.com/woodstock-theme-doc/index.html#toc

for more information on this topic.

-rick

mike.r.phillips wrote:

>Can woodstock localization be based on the users current browser language
>choice(request.getLocale())?
>
>After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
>I can only get the correct localized strings and buttons used by the
>underlying components to be used if I add
>a JVM option "-Duser.language=de" to the app server, or if I use
>Locale.setDefault(choosenLocale) and then
>re-deploy my app.
>
>if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create
>that are not part of
>underlying components are localized correctly and change for each user base
>on browser preference.
>
>Is there a way to tell components to reload the localized strings without
>bouncing app server?
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@woodstock.dev.java.net
For additional commands, e-mail: dev-help@woodstock.dev.java.net

Re: Localization on the fly

by richard ratta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

mike.r.phillips wrote:
We are using the version of woodstock that comes in netbeans 5.5. 

I just ran a test on netbeans 6.1 and you are correct the localization is
controlled by browser locale just the way
I would like.

Problem is we couldn't switch to new netbeans and woodstock because
performance was so poor. Is there
a way to get this localization behavior from the woodstock that comes with
5.5

Is there a way to list out the woodstock version?
  
Yes.
Each jar has a manifest.
If you jar xf webui-jsf.jar META-INF/MANIFEST.MF
and dump the MANIFEST.MF you will see a version designation.
And likewise for the theme jar webui-jsf-suntheme.jar (I think).

As far as I remember since JSF 1.2 (after they fixed their localization problems)
the browser locale always controlled the locale of the components.

Before 1.2 there was JSF bug where in some cases (based on server or client state mode)
you had to restart the webapp.

Now if you are working in the IDE there are other issues involved with the design
surface and locale, and those I never understood.

-rick

richard ratta wrote:
  
What version of woodstock are you using ?

The last I remember is that the locale IS determined based on browser 
locale and
you should not have to do anything else to see this.

Now the gotcha...

Depending on which version of woodstock you are using you have to
make sure that the javascript theme also reflects the localizations you 
are setting
in "messages_de.properties.".

In the later versions of woodstock, especially for components that have
widget renderers, the javascript theme must have all the localizations 
that exist
in properties files. This is accomplished in the build of the "theme".

See

http://webdev2.sun.com/woodstock-theme-doc/index.html#toc

for more information on this topic.

-rick

mike.r.phillips wrote:

    
Can woodstock localization be based on the users current browser language
choice(request.getLocale())? 

After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
I can only get the correct localized strings and buttons used by the
underlying components to be used if I add
a JVM option "-Duser.language=de" to the app server, or if I use
Locale.setDefault(choosenLocale) and then
re-deploy my app.

if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create
that are not part of
underlying components are localized correctly and change for each user
      
base
  
on browser preference.

Is there a way to tell components to reload the localized strings without
bouncing app server? 
 

      
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...



    

  

--------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@... For additional commands, e-mail: dev-help@...

Re: Localization on the fly

by mike.r.phillips :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

We are using woodstock version ...
Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
Implementation-Title: Woodstock Components 4.0 Theme: suntheme

The link you gave me gave me an idea. It may be a bad idea but it works.
If I use the following code the page renders with the new locale information even for the
woodstock components. It is not automatic but at least I can bind it to a choose locale button, and
work from there.
  public String button3_action()
  {
    FacesContext        fc = this.getFacesContext();
    HttpServletRequest  req = (HttpServletRequest) fc.getExternalContext().getRequest();

    JSFThemeContext tc = (JSFThemeContext) JSFThemeContext.getInstance(fc);
    tc.setDefaultLocale(req.getLocale());

    return "DBOrderTest";
  }

mike.r.phillips wrote:
Can woodstock localization be based on the users current browser language choice(request.getLocale())?

After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
I can only get the correct localized strings and buttons used by the underlying components to be used if I add
a JVM option "-Duser.language=de" to the app server, or if I use Locale.setDefault(choosenLocale) and then
re-deploy my app.

if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create that are not part of
underlying components are localized correctly and change for each user base on browser preference.

Is there a way to tell components to reload the localized strings without bouncing app server?

Re: Localization on the fly

by richard ratta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

You're right, its not a good way to do this ;)

If this is for your private web app and not a change to the Woodstock
code, then
that's different but if you plan on changing woodstock then I would
suggest you not do that.


But given that the code has "JSFThemeContext" means that you should not
have to
do this at all. There is something else going on that is not allowing
the browser
locale to control the locale of the components.

Note that in order for the locale to change, a request for the whole
page must be
made. It cannot be an ajax request for a single component, in case you
are using
ajax in your page.

Also make sure you are satisfying all the JSF requirements of listing the
supported locales in the faces config file.

I'm not sure but if this is an early version of woodstock then there was
a bug
where supported locales must be listed in the web.xml of the web app.
I can't remember when that was fixed, but it was in a version when
the "JSFThemeContext" came into being. This new theme code eliminated
the need for supported locales to be listed in web.xm of the web app
but in the early release of it, I think there was a bug.

The real answer is to upgrade to the later version of the components.

-rick

mike.r.phillips wrote:

>We are using woodstock version ...
>Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>Implementation-Title: Woodstock Components 4.0 Theme: suntheme
>
>The link you gave me gave me an idea. It may be a bad idea but it works.
>If I use the following code the page renders with the new locale information
>even for the
>woodstock components. It is not automatic but at least I can bind it to a
>choose locale button, and
>work from there.
>  public String button3_action()
>  {
>    FacesContext        fc = this.getFacesContext();
>    HttpServletRequest  req = (HttpServletRequest)
>fc.getExternalContext().getRequest();
>
>    JSFThemeContext tc = (JSFThemeContext) JSFThemeContext.getInstance(fc);
>    tc.setDefaultLocale(req.getLocale());
>
>    return "DBOrderTest";
>  }
>
>
>mike.r.phillips wrote:
>  
>
>>Can woodstock localization be based on the users current browser language
>>choice(request.getLocale())?
>>
>>After creating a sun/webui/jsf/suntheme/messages/messages_de.properties
>>I can only get the correct localized strings and buttons used by the
>>underlying components to be used if I add
>>a JVM option "-Duser.language=de" to the app server, or if I use
>>Locale.setDefault(choosenLocale) and then
>>re-deploy my app.
>>
>>if I use <f:view locale="<%= request.getLocale() %>"> the bundles I create
>>that are not part of
>>underlying components are localized correctly and change for each user
>>base on browser preference.
>>
>>Is there a way to tell components to reload the localized strings without
>>bouncing app server?
>>
>>    
>>
>
>  
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...


Re: Localization on the fly

by mike.r.phillips :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Yes, Here is the answer if you are using woodstock 4.0 and netbeans 5.5.
You must set the locales you want to support in both
faces_config.xml
  <application>
    <locale-config>
       <supported-locale>en</supported-locale>
       <supported-locale>de</supported-locale>
     </locale-config>
  </application>

and web.xml
  <context-param>
    <param-name>com.sun.webui.theme.SUPPORTED_LOCALES</param-name>
    <param-value>en,de</param-value>
  </context-param>

With this, when you set your language to german or english in your browser, the web app shows either localized version

Re: Localization on the fly

by richard ratta :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


mike.r.phillips wrote:

> Yes, Here is the answer if you are using woodstock 4.0 and netbeans 5.5.
> You must set the locales you want to support in both
> faces_config.xml
>   <application>
>     <locale-config>
>        <supported-locale>en</supported-locale>
>        <supported-locale>de</supported-locale>
>      </locale-config>
>   </application>
>  
And the web.xml part is no longer necessary in later versions.

> and web.xml
>   <context-param>
>     <param-name>com.sun.webui.theme.SUPPORTED_LOCALES</param-name>
>     <param-value>en,de</param-value>
>   </context-param>
>
> With this, when you set your language to german or english in your browser,
> the web app shows either localized version
>  

-rick

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...