Internationalization in JSF

[http://jsflessons.blogspot.com/p/internationalization.html]

Good article ..
I have to give internationalization support for an exsisting JSF application. I don't want to go and update the view tag in all my jsp pages.
Is there any other way to do this by modifying a single class in my project, other than the two options given in the article?

Similar Messages

CSS layout and Internationalization of JSF apps

We use message bundles to handle internationalization in our JSF applications. This approach seems to work as we used HTML tables (or rather <h:panelGrid> tags) to layout components on the page.
We had numerous customer complaints about tons of extra white space left on the screen in languages like German (where some words are very long). There are other issues with grid layouts, and we decided to give CSS positioning a try.
I wonder, what folks on this forum think about using CSSP in conjunciton with JSF components. Also, given that text strings have different length in different languages, what is the i18n approach? Afterall, coordinates that work in English may not be accurate in German.
Any suggestions, ideas, pointers would be greatly appreciated.
Thanks,
Vadim.

Hi guys.
The problem seems a little bit weird. But you could try the following. It is just the idea.
1. You should recover the .properties file and get the Map for the current Locale. This should have to be done maybe in the Backing bean.
2. Get the maximum length of the UIOutputText elements present in the form that you need to control its length. Now the important thing here is that you should have the value atribute of the UIOutputText objects based on an internationalized Base Bundle prefix. Just cut -based on the substring of the value attribute- the name of the property.
3. Consider that you have to look in the Map the entry you just obtained from the UIOutputText object. After get the value of that Map entry (a String object) and get its length. At the end of the loop you sould have get the maximum length in characters of the component values to be displayed.
4. Fix that value as an attribute in the backing bean.
5. Use the output of that value to generate the style in CSS, as an String attribute of the Backing Bean. Base your CSS construction in "em" measures
6. Change the -style- attribute in each component to reflect the correct length using CSS like this -style="#�{backingBeanName.style}"-. With this you will get an space dependent of the length of the localized values.
Again. It is just a suggestion, I had not tried it already but I guess that will be my way in that case.
Greets from Ecuador

How to use Hindi as internationalization in JSF

could you pls help in this topic

Just the same way as you do in JSP. Since JSF 1.2 you can use unified EL #{ } in c:forEach.
You can also use Tomahawk's [t:dataList|http://myfaces.apache.org/tomahawk-project/tomahawk12/tagdoc/t_dataList.html] by the way. It is more efficient.

Internationalization with JSF

Hi Everyone,
Here is what happens in my App:
When index.jsp is hit, I determine wether its an authorized/unauthorized login. Based on that user is either forwarded to search/error jsp's. Now I have to add Multi Lingual support to the app. Basically the aplication will be invoked from a portal like app so the URL will look like this :
http://xyz.corp.xyz.com:7780/appsell_uat_xyz/faces/index.jsp?&languageCd=ENG&userId=MPENIKELAPATI
Now I am supposed the pick up the language from the above URL and set the locale accordingly.
I want to set the locale while I am on index.jsp only determing access authority. The way I tried to do this is (I have a bean asociated with index.jsp, this code goes in that bean) :
if(languageCd == "JA"){
context.getViewRoot().setLocale(Locale.JAPANESE);
Faces config:
<navigation-rule>
<from-view-id>/index.jsp</from-view-id>
<navigation-case>
<from-outcome>success</from-outcome>
<to-view-id>/search.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
<navigation-rule>
<from-view-id>/index.jsp</from-view-id>
<navigation-case>
<from-outcome>error</from-outcome>
<to-view-id>/error.jsp</to-view-id>
<redirect/>
</navigation-case>
</navigation-rule>
<application>
    <locale-config>
      <default-locale>en</default-locale>
      <supported-locale>ja</supported-locale>
    </locale-config>
</application>Problem here is if I try to set the local in index.jsp only, viewRoot is not search.jsp yet. So the labels are of default locale. I also tried to set the local in the constructor of search.jsp. This works, but is a very unclean solution as on all the hits code will be executed. One additional problem with this approach is when control is redirecting from index to search jsp, I see all the labels in English for a very small time then the labeles change to Japanease.
I think I dont understand Localization approach of JSF at all. I read local will be picked up from browser setting, but I dont know how will that behave.
I will appreciate a great deal if someone can clear my concepts here!
Thanks in advance!

Yes, by default JSF will use the locale from the client, determined from the Accept-Language header. If this is not suitable to your application, I recommend using a servlet filter to set the locale according to your scheme by wrapping the request object and overriding ServeltRequest.getLocale(). You could determine the locale once from URL and then store it in the session or a cookie, whichever suits your needs.

Announce: Guise framework addresses JSF shortcomings

JSF developers may be interested in learning of the release of a new framework named Guise(TM), which is now available free for development use:
http://www.javaguise.com/
I've been involved in the JSF forum for many months, as I spent countless frustrating hours trying to coax JSF into doing what I believed were simple, obvious things. As you can see on this forum, I've written a whole new value-binding expression syntax and framework just so I could pass parameters to methods. I've had to rewrite several JSF renderers just so the output it creates would not break my XHTML files. I've had to create a new component and associated framework just to upload files. I've kept the JSF community updated with my progress, but eventually I found myself rewriting the JSF framework more than I was writing application code. Guise(TM) is the solution I created for my JSF problems.
I'll admit that I first approached JSF with the wrong mindset, thinking that it was some sort of procedural scripting language like JSP. I soon adopted a component mindset whole-heartedly, only to be disillusioned: although JSF may claim to be definition-file agnostic, in reality it was built on top of JSP and jumps through a thousand crazy hoops just so people can define their components in JSP. Hans Bergsten infamously advocated (see http://www.onjava.com/pub/a/onjava/2004/06/09/jsf.html ) dumping JSP to save JSF, but even getting rid of JSF would still leave a framework that scatters type-unsafe strings throughout the source code and multiple configuration files, and provides wildly inefficient event delgation through many error-prone levels of an impotent expression language. That's not even considering finding the right combination of component IDs so that I can send back a validation error that will appear in the correct location on my web page.
I was getting ready to recommend to one of my clients a framework for their redesigned web application. I pondered what I would recommend---JSP+EJB? Struts? JavaServer Faces? In the end I realized that none of these provide anything close to the simple, safe, robust UI frameworks we're used to working with on the client. I wanted something that can be used like Java Swing, yet is simpler and more elegant, and uses generics. Since I was calling the shots, I decided that I wanted the UI to work on the client or across the web with no code changes.
So I wrote Guise(TM)---a graphical user interface framework in Java designed from the ground up to be both simple and elegant. Consider this example "Hello User" program, available at http://www.javaguise.com/demonstration
public class HelloUserFrame extends DefaultFrame
public HelloUserFrame(GuiseSession<?> session)
    super(session, new FlowLayout(Orientation.Flow.PAGE));
    getModel().setLabel("Guise\u2122 Demonstration: Hello User");
    Label helloUserLabel=new Label(session);
    helloUserLabel.setVisible(false);
    add(helloUserLabel);
    TextControl<String> userInput=new TextControl<String>(session, String.class);
    userInput.getModel().setLabel("What's your name?");
    userInput.getModel().setValidator(new RegularExpressionStringValidator(session, "\\S+.*", true));
    userInput.getModel().addPropertyChangeListener(ValueModel.VALUE_PROPERTY,
        new AbstractPropertyValueChangeListener<String>()
          public void propertyValueChange(PropertyValueChangeEvent<String> propertyValueChangeEvent)
            String user=propertyValueChangeEvent.getNewValue();
            helloUserLabel.getModel().setLabel("Hello, "+user+"!");
            helloUserLabel.setVisible(true);
    add(userInput);
}No, this isn't Swing---it's Guise. The above example is all type-safe; the only hard-coded strings for this example is a declaration in the web.xml file binding the class to a navigation path. Forget "backing beans". Forget unsafe strings littering a multitude of configuration files. Try Guise, and you be the judge.
Here are some reasons you may like Guise:
* No JSP!
* Allows the web equivalent of modal dialogs.
* Quick and easy setup.
* Elegant ultra-MVC, with encapsulated models and controllers. No need for complicated backing beans and inflexible expression language---just use Java like you normally would.
* Instantiate components, plug in validators, add action listeners, and report errors directly instead of using cumbersome, error-prone, and type-unsafe strings scattered in various configuration files and source code.
* Java generics supported throughout.
* File uploads built in.
* Customizable, robust, authentication and authorization built in. Client-based authentication and login-based authentication can be seamlessly intermixed.
* Buttons are rendered with real buttons that allow icons and other rich content, and automatically work around the IE button bugs.
* Output is 100% XHTML compliant, with automatic downgrading from content type "application/xhtml+xml" to "text/html" for buggy clients (such as IE 6) which crash when the W3C specification for XHTML content type is followed.
* Validation errors are automatically associated with components, and appear automatically on the web page. An error dialog box is also presented indicating the errors.
* Internationalization is built in. Each application is aware of its supported locales and the selected locale of each session. Set a control model's resource key, and the correct value will automatically be loaded at runtime.
* Parameters can be sent in the URI query string.
* Multiple components can share the same model.
* List selection controls implement the java.util.List interface and support generic values.
* The Guise framework is thread-safe.
I realize that although it's likely the release of Guise will be of interest to the JSF community, in-depth discussion of the framework is probably off-topic for the JSF Forum. I welcome further discussion of Guise, along with inquiries, at [email protected] . Further information may be found at http://www.javaguise.com/ .
Sincerely,
Garret

Ed,
I appreciate your innovation in creating a new
Framework, I'm of course very interested to hear
specifics about why you chose to do so. Which
shortcomings in JSF exactly are you trying to fix?Thanks for the concern. If you look through the posts I've made to this forum, you'll get an idea of the heartache I've went through with JSF. Let me give you an overview. (I've provided appropriate citations to the related forum discussions.)
Iteration
One of the big newbie complaints you'll hear is that JSF won't work with JSTL---in particular, the JSTL iterators. I ran into this problem early on, and decried the lack of no iterator replacement. Adam Winer explained all the "pain... pain... more pain" it would take to create an iterator in JSF that would work with other components. After I became experienced with JSF and dug through the source code for months, I pointed out that UIData already goes through all this pain and needs to be refactored---UIData is really a UIIterator with a tad bit of table-specific stuff thrown in. http://forum.java.sun.com/thread.jspa?threadID=557278
But the complaints and debates about iteration reveal a more fundamental problem with JSF. At its heart it is declarative---a fault it inherits from its close relationship with JSP. Tables, for example, are defined as a static relationship defined forever-in-stone in (for example) a JSP. Because we all want dynamic data in tables, JSF allows us to declare a programmatic relationship between table rows and the table, resulting in secret counters that get incremented and decremented in the background as rendering occurs, along with associated bugs in nested tables. A render phase is simply not the place to put dynamic application logic, but in JSF that's the only place to put it if you follow the paradigm. And you must do the same strange variable counts in the the other phases, just so you can wind up with the correct bindings for the correct row.
Because JSF forces application logic into the render phase, I have to create something like a UIAssignment component that pretends to be a static component in the hierarchy, yet really performs variable assignment as JSF goes through the rendering process. I have to rely on the implementation rendering in the correct order, and I have to add with intricate logic to work around hidden/visible settings that might alter the rendering procedure and hence defeat the assignment algorithm. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=576178
Guise is not built on top of JSP, and hence doesn't force one to put rendering-related hacks into the application code. Check out the elegant Guise table model, for instance. It's very similar to the Swing table model, but simpler, more elegant, and with generics. Rather than play with counters and rendering in the application logic, you can just reference Java objects as you would normally. This entire issue of iteration is also related to the "Loose, Late Binding" issue and the "Impotent Expression Language" problem, which I discuss below.
Loose, Late Binding
Because JSF uses the "pretend not to be tied to JSP but support JSP in the archictecture" paradigm, the components are so uncoupled from the application code that any event logic must use a separate expression language. This language is not checked until runtime. I could put the string "Bill Murray" in an expression, and I'd never know about the problem until someone tries to access that page. Similarly, any expressions are so loosely bound that I don't know to what extent they actually work with my code until I start up the web server.
What happens if I want to respond to an event in JSF? Well, first I have to create a "backing bean," a special mediator to help my components and application work together. Then I have to create an un-typesafe string in a non-Java language that binds something that happpens on the component with the backing bean, which will in response do something with my application. Something like:
<h:commandButton action="#{myBackingBean.doSomething}" value="Test"/>Then (as if this weren't enough) I have to find some configuration file somewhere in order to define my backing bean (it doesn't work automatically). Needless to say, this definition also isn't typesafe and is not verified until runtime. All this just to respond to a button being pressed?
Guise doesn't need an expression language, backing beans, or backing bean configuration files. If I want to repond to a button being pressed, I just listen for it---right in the Java code:
myButton.getModel().addActionListener(...)Everything is typesafe (with generics, I might add). If there's a syntax problem, you'll know it when your program doesn't compile. Your code becomes much more efficient because the expression string doesn't have to be parsed, a variable-binding object doesn't need to be created, and a backing bean doesn't need to be looked up every time the page renders. It just works like you expect Java to work. Simple and elegant.
But the loose, late binding doesn't stop at the expression language. Binding components to IDs in faces-config.xml isn't typesafe. Assigning renderers in faces-config.xml isn't typesafe. In fact, even programmatically creating a component at runtime forces me to use some arbitrary string that isn't tied to anything except some lookup map somewhere that I hope has been properly configured by faces-config.xml and the various components and renderers. Changing component properties at runtime requires several levels of un-typesafe string processing. String, strings, strings---JSF brings Java back to BASIC, as it were.
If I want to create a component in Guise, on the other hand, I do it like I'd create anything else in Java:
Label=new Label(session);If I want to associate a controller with a component in Guise, I'm not just passing around opaque strings. Here's a line out of XHTMLControllerKit:
registerController(Label.class, XHTMLLabelController.class);
Impotent Expression Language
It's bad enough that we have to mess with expression languages, but the JSF expression language is impotent that I can't even pass arguments to methods! (The argument that JSP doesn't allow them either falls on deaf ears---JSF isn't tied to JSP, right?) Doing simple things like selecting an item from a list becomes virtually impossible (if you want to keep your elegantly-factored backend code) without argument passing. That's why I was forced to create an entire new expression language on top of JSF-EL just to allow parameters to methods. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=561520 And (combined with the iteration problem, above) I had to create a UIAssignment that pretends to be a component yet really performs variable assignment in the background, using my extended JSF-EL. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=563036
Internationalization
Support for internationalization in JSF (and even in Swing) is provided in a sort of ad-hoc, last-minute manner. Guise has internationalization support built in from the ground up. Each component model can be given a resource key, which will automatically get the correct data based upon the session locale.
Guise handles internationalization of component layout automatically as well. Check out the internationalization demo at http://www.javaguise.com/demonstration ---just by changing the session locale, the entire component hierarchy reorients itself automatically and loads the correct resources. That's done with one line of application code!
File Uploads
JSF doesn't support file uploads, and I had to concoct an entire file upload framework for JSF. http://forum.java.sun.com/thread.jspa?forumID=427&threadID=464060
Guise has elegant, validating file upload support built in.
In the end, I just wanted to write an application for the web like I would for Swing, without resorting to a mindset of a couple of decades ago when typesafeness was unknown and event delegation wasn't elegant. Since we have Java 5.0, I also wanted to use generics. I just wanted to program using best practices rather than setting up endless text-based configuration files. I wanted Guise(TM). So I wrote it.
Also, would you consider joining the JCP expert group
working on JSF? The whole point of the JCP is to
allow people with big ideas like yourself to help
grow the core platform.On 21 October 2004, I wrote on this forum, "I'm willing (and eager) to join the expert group and put in my effort to help effect these changes in the specification..." http://forum.java.sun.com/thread.jspa?forumID=427&threadID=565052
I then requested directly to join, and Roger Kitain replied that, "Currently, the group has quite a few members, so I'm not adding any more members unless their background is an exceptionally good fit." On 24 January 2005 I provided extensive coverage of my qualifications to both you and Roger.
On 17 March 2005 I indicated I was still willing to join, but Roger had already pointed out the catch on 7 February 2005: in order for me to spend my time and provide my expertise to contribute to the advancement of JSF, I must pay Sun $5,000. It wasn't enough that I was offering my services for free---Sun wanted me to pay them to allow me to contribute to bettering JSF.
I hope this overview answers your question about the shortcomings of JSF. If you have any more questions, I'll be happy to answer them. You may be interested in reading more about the basics of the Guise(TM) framework at http://www.javaguise.com/overview and constrasting the Guise approach to that of JSF.
Sincerely,
Garret

[JSF 1.2 and 2.0/Internationalization] How to propagate the Locale to the entire application

Hi,
do you know how to internationalize an application in a dynamic way in JSF 1.2 ?
I created 2 files msg_fr.properties ( language by default, french) and msg_en.properties ( english)
Then I wrote a methode changeLanguage() in a Managed Bean . This method allows me to switcher the language in the first page of the application.
This method is called in a tag <h:commandLink>
public void changeLanguage() {
        FacesContext context = FacesContext.getCurrentInstance();
        // I test a parameter (currentLanguage) and I switch in consequence
       context.getViewRoot().setLocale(Locale.ENGLISH);
       //or    context.getViewRoot().setLocale(Locale.FRENCH);
       context.getApplication().setDefaultLocale(context.getViewRoot().getLocale()); I have of course modified the file faces-config.xml.
This WORKS but for the current page only. The Locale is not propagated to the next pages of the application.
The Locale by default of my browser is English and so the next pages are always in English, even if i switch the first page to French.
Do you know how to propagate this Locale to all the pages of the application in JSF 1.2 ?
Also, has internationalization been improved in JSF 2.0 ?
thanks

The f:view has a 'locale' attribute. You should make use of it. Feed it with a property of a session scoped bean which you could control/change using for example some language dropdown menu or a request parameter or pathinfo. There is no need to traverse the FacesContext and UIViewRoot yourself.
For more about i18n in JSF, please consult the Sun JSF specification and the Sun Java EE tutorial.

How to internationalize images, css, js in JSF?

Hi All,
Just came to my mind and haven't think of it thoroughly but any better ideas how to internationalize the images, css, or js?
For example:
1. when the user's Locale is en, it will loads logo_en.jpg
2. when the user's Locale is ja, it will loads logo_ja.jpg
First came to my mind is to use the resource bundle (using its key=value pair).
Much thanks,
Eson.

InDesign works on a different model. It might be best to adjust your thinking away from "float/clear."
In page layout, it is "Text Wrap." You apply text wrap to your image, and any text that would otherwise occupy the same space will flow around the image instead. In the Text Wrap panel, you can adjust offsets, (or perhaps it would be more accurate to think of them as 'stand-offs' or 'padding'), to push the text away or draw it closer.

JSF Internationalization in arabic

Hi,
i have to display JSF page in Arabic language
I have stored properties file in arabic using UTF-8 character encoding
and save properties file for eg messages_ar.properties
But Jsf page is displaying garbage charaters in place of arabic value
My JSF page contains:
<%@ page contentType="text/html; charset=UTF-8" %>
meta tag
<meta http-equiv="content-type" content="text/html; charset=utf-8" />
and even set encoding on html as UTF-8
but still no effect
Please help me out its urgent
Thanks
akashikha

Hi,
Try this...
when viewing in a browser, you could try setting the encoding (on the view menu normally) to arabic (ISO-8859-6).
But I am not sure have you done it or not?
Edited by: Sat@301177 on Feb 20, 2008 4:51 AM

JSF webapp works with Java 1.4, but not Java EE 5

Hello
I am having a really weird problem with internationalizing my JavaServer Faces web application.
I am using Netbeans 6.0, Tomcat 6.0.10, JSF 1.2, and JTSL 1.1....
If I use Java 1.4 to run the webapp, everything works fine!
If I use Java EE 5 then it fails to execute internationalization of my choosen locale.
I could just use Java 1.4 and have my site working fine, but I would really like to use Java EE 5 since it can do more. Also I don't see why it can work on one version of Java but not another. My locales are English (en) and Korean (ko).
This is my index.jsp
<%--
    Document   : index
    Created on : 2/05/2008, 01:33:01
    Author     : Steve
--%>
<%@page contentType="text/html" pageEncoding="UTF-8"%>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<%@taglib prefix="f" uri="http://java.sun.com/jsf/core"%>
<%@taglib prefix="h" uri="http://java.sun.com/jsf/html"%>
<%@taglib prefix="c" uri="http://java.sun.com/jstl/core"%>
<html>
    <f:view locale="#{localeBean.language}">
        <f:loadBundle basename="resources.messages" var="msg"/>
        <head>
            <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
            <title>JSP Page</title>
        </head>
        <body>
            <h2>Hello <h:outputText value="#{localeBean.country}"/>!</h2>
            <br>
            <h4><h:outputText value="#{msg.language}"/>:</h4>
            <h:form id="languageForm">
                <h:selectOneMenu   onchange="this.form.submit();" valueChangeListener="#{localeBean.dropdown1_processValueChange}">
                    <f:selectItem itemLabel="English" itemValue="en"/>
                    <f:selectItem itemLabel="��" itemValue="ko"/>
                </h:selectOneMenu>
            </h:form>
            <h:outputText value="#{localeBean.language}"/>
        </body>
    </f:view>
</html>This is my localeBean which is under the package "resources"
* To change this template, choose Tools | Templates
* and open the template in the editor.
package resources;
* @author Steve
import java.util.Locale;
import javax.faces.event.ValueChangeEvent;
public class localeBean {
    private String language = Locale.getDefault().getLanguage();
    private String country = Locale.getDefault().getCountry();
    public String getLanguage() {
        return language;
    public void setLanguage(String newValue) {
        language = newValue;
    public String getCountry() {
        return country;
    public void setCountry(String newValue) {
        country = newValue;
    public void dropdown1_processValueChange(ValueChangeEvent vce) {
        setLanguage((String) vce.getNewValue());
}This is my faces-config file
<?xml version='1.0' encoding='UTF-8'?>

<faces-config version="1.2"
    xmlns="http://java.sun.com/xml/ns/javaee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-facesconfig_1_2.xsd">
<application>
        <locale-config>
            <default-locale>en</default-locale>
            <supported-locale>en</supported-locale>
            <supported-locale>ko</supported-locale>
        </locale-config>
        <message-bundle> resources.messages </message-bundle>
    </application>
    <managed-bean>
        <managed-bean-name>localeBean</managed-bean-name>
        <managed-bean-class>resources.localeBean</managed-bean-class>
        <managed-bean-scope>session</managed-bean-scope>
    </managed-bean>
</faces-config>and lastly I have my message bundle under the "resources" package which is named "messages".
This has a key word "language" which is "Language" in the 'en' locale file and "��" in the 'ko' locale file.
Once again when using Java 1.4 this project runs fine, however with Java EE 5 it does not.
You may notice in my index.jsp that I have <h:outputText value="#{localeBean.language}"/>
I use this to display the locale that has been chosen by my select box. Even when this shows a different language has been chosen the page does still not display in the correct language. According to <f:view locale="#{localeBean.language}"> then the locale of the page should be changed.
I have looked over the web quite far for an answer to this problem. But everyone else seems to be using a similar method of loading up a message bundle and using it the same way I am. However my method does not work.
Any suggestions or clues to what is going wrong would be really appreciated.
Thanks in advance^^

it seems that the
<f:view locale="en">
only work if a ressource bundle with the locale sufix '_en' is provided.
Everything works now if I provide 3 ressouce files:
global_en.properties
global_de.properties
global.properties
global.properties and global_en.properties are identically!
But if I delete the global_en.properties file always the global_de.properties file wins before the default properties.
I did not expect such a behavior :-(

Why isn't my jsf app internationalizing?

Hello all -
Using NB 6.5.1, JDK 6, Java EE 5, and Glassfish V3, so nothing but the good stuff. This should be simple for anyone who is already internationalizing their apps, so please assist.
New to i18n but badly needing to grasp it, I have developed the following mini project that should change its displayed language but only based on user choice, and not the browser's settings.
1) created a jsf web app project (called langs) with Visual Web Java Serverfaces support
2) dragged & dropped (d&d) a dropdown list object and configured it with two items: en and fr for English and French. Also, made it "Auto-submit on change" and provided it this event handler:
   public void dropDown1_processValueChange(ValueChangeEvent event) {
      FacesContext context = FacesContext.getCurrentInstance();
      UIViewRoot viewRoot = context.getViewRoot();
      String loc = dropDown1.getSelected().toString();
      viewRoot.setLocale(new Locale(loc));
      info("Locale: " + viewRoot.getLocale().toString());
   }3) d&d a loadBundle object into the jsf page, so the jsp version of the page now has this tag:
<f:loadBundle basename="langs.Bundle" var="msg1"/>4) added one locale, this is the "fr_FR - French / France" as shown in the "New Locale" dialog
5) into the Bundle.properties file, I added one key: "welcome", with default language: "hello", and fr_FR - French language: "au revoir"
6) d&d a label object onto the page, and set its text as follows: #{msg1.welcome}. As soon as I do that, the text is shown rendered on the development page to "hello", so I am accessing the file OK.
7) ... and that's it. I run the program, all I ever see is the word "hello". I change the selection from the drop down list of course and the page refreshes, but all I see is "hello". I check print out the value of the viewRoot's locale and it shown me either "en" or "fr" in accordance with my selection, but the displayed string is "hello".
I have been stuck with this for (well, I am shy to say) sometime now and I really need to solve it. What am I "not" doing? I must be missing something that makes the app oblivious to the file named Bundle_fr_FR.properties (the other one of course is Bundle.properties).
And while we are it, can I pick and choose my bundle files dynamically from within the application to force the app to get the values for the keys from a certain file? For example, suppose I want to internationalize and app into 7 languages (some LTR, others RTL) and I don't want to put all the values for the keys in one "basename" file, could I do that?
Your answer and pointers are much, much appreciated. Thank you.
Mohsen

Why not get sun's J2EE tutorial and follow the steps explained there.
Even if you insist on using Netbeans' drag and drop facilities, you could still view the source to make sure that it matches what's explained in the tutorial. I find that doing some things manually first helps me understand and appreciate the processes better when I later use a tool to speed up development.

JSF and Character Sets (UTF-8)

Hi all,
This question might have been asked before, but I'm going to ask it anyway because I'm completely puzzled by how this works in JSF.
Let's begin with the basics, I have an application running on an OC4J servlet container, and am using JSF 1.1 (MyFaces). The problems I am having with this setup, is that it seems that the character encodings I want the server/client to use are not coming across correctly. I'm trying to enforce the application to be UTF-8, but after the response is rendered to my client, I've magically been reverted to ISO-8859-1, which is the main character set for the netherlands. However, I'm building the application to support proper internationalization; which means I NEED to use UTF-8.
I've executed the following steps to reach this goal:
- All JSP files contain page directives, noting the character set:
<%@ page pageEncoding="UTF-8" contentType="text/html; charset=UTF-8" %>I've checked the generated source that comes from the JSP's, it looks as expected.
- I've created a servlet filter to set the character set directly on the request and response objects:
    public void doFilter(ServletRequest req, ServletResponse res, FilterChain chain) throws IOException, ServletException {
        // Set the characterencoding for the request and response streams.
        req.setCharacterEncoding("UTF-8");
        res.setContentType("text/html; charset=UTF-8");
        // Complete (continue) the processing chain.
        chain.doFilter(req, res);
    }I've debugged the code, and this works fine, except for where JSF comes in. If I use the above situation, without going through JSF, my pages come back UTF-8. When I go through JSF, my pages come back as ISO-8859-1. I'm baffled as to what is causing this. On several forums, writing a filter was proposed as the solution, however this doesn't do it for me.
It looks like somewhere internally in JSF the character set is changed to ISO. I've been through the sources, and I've found several pieces of code that support that theory. I've seen portions of code where the character set for the response is set to that of the request. Which in my case coming from a dutch system, will be ISO.
How can this be prevented? Can anyone give some good insight on the inner workings of JSF with regards to character sets in specific? Could this be a servlet container problem?
Many thanks in advance for your assistance,
Jarno

Jarno,
I've been investigating JSF and character encodings a bit this weekend. And I have to say it's more than a little confusing. But I may have a little insight as to what's going on here.
I have a post here:
http://forum.java.sun.com/thread.jspa?threadID=725929&tstart=45
where I have a number of open questions regarding JSF 1.2's intended handling of character encodings. Please feel free to comment, as you're clearly struggling with some of the same questions I have.
In MyFaces JSF 1.1 and JSF-RI 1.2 the handling appears to be dependent on the raw Content-Type header. Looking at the MyFaces implementation here -
http://svn.apache.org/repos/asf/myfaces/legacy/tags/JSF_1_1_started/src/myfaces/org/apache/myfaces/application/jsp/JspViewHandlerImpl.java
(which I'm not sure is the correct code, but it's the best I've found) it looks like the raw header Content-Type header is being parsed in handleCharacterEncoding. The resulting value (if not null) is used to set the request character encoding.
The JSF-RI 1.2 code is similar - calculateCharacterEncoding(FacesContext) in ViewHandler appears to parse the raw header, as opposed to using the CharacterEncoding getter on ServletRequest. This is understandable, as this code should be able to handle PortletRequests as well as ServletRequests. And PortletRequests don't have set/getCharacterEncoding methods.
My first thought is that calling setCharacterEncoding on the request in the filter may not update the raw Content-Type header. (I haven't checked if this is the case) If it doesn't, then the raw header may be getting reparsed and the request encoding getting reset in the ViewHandler. I'd suggest that you check the state of the Content-Type header before and after your call to req.setCharacterEncoding('UTF-8"). If the header charset value is unset or unchanged after this call, you may want to update it manually in your Filter.
If that doesn't work, I'd suggest writing a simple ViewHandler which prints out the request's character encoding and the value of the Content-Type header to your logs before and after the calls to the underlying ViewHandler for each major method (i.e. renderView, etc.)
Not sure if that's helpful, but it's my best advice based on the understanding I've reached to date. And I definitely agree - documentation on this point appears to be lacking. Good luck
Regards,
Peter

Email sturen with JSF

Hi,
I am developping a site with JSF.. If the user fills insome information, tan automatic email should be sent to hem..
Can someone help me to do that?
Thanks

The main components of JavaServer Faces technology are as follows:
* An API for representing UI components and managing their state; handling events, server-side validation, and data conversion; defining page navigation; supporting internationalization and accessibility; and providing extensibility for all these features
* Two JavaServer Pages (JSP) custom tag libraries for expressing UI components within a JSP page and for wiring components to server-side objects.

10g BPM JSP/JSF Internationalisatio problem

Can anyone help me here? I'm trying to internationalise the labels in a 10g BPM custom JSP (JSF) presentation but I can't work out where to put the language bundle so the tags can pick them up.
I use
     <f:loadBundle baseName="labels" var="labels"/>
to get the bundle and
     <h:outputText value="#{labels.decisionHeader}" style="text-align:left;"/>
to display the text. However wherever I put the properties file in the workspace IN BPM Studio, I get
RUNTIME: Unexpected Error:The task could not be successfully executed.
RUNTIME: Reason: 'fuego.web.execution.exception.InternalForwardException: UnExpe
cted error during internal forward process.'.
when I try to open the manual task from the workspace. Anyone had any luck with this?
Matthew

I handle internationalization a little differently...
At the top of my jsp, I have:
<%@ taglib uri="http://java.sun.com/jstl/core" prefix="c" %>
<%@ taglib uri="http://fuego.com/jsp/ftl" prefix="f" %>
<%@ taglib uri="http://java.sun.com/jstl/fmt" prefix="fmt" %>
<fmt:setLocale value='${pageContext.request.locale}' scope="session"/>
<fmt:setBundle basename="languageFile" scope="session" />Then, put the languageFile_en.properties in the following location: (other langauges would have the file name _<languageCode>.properties extension.
<ObpmHome>\webapps\workspace\WEB-INF\classes
This looks at what the browser has set for language, and reads the proper file...
Use of the language properties looks like:
<table class="header_bar">
     <tr>
          <td class="past"><fmt:message key="pro_bar_requester"/></td>
          <td class="past"><fmt:message key="pro_bar_coi"/></td>
          <td class="past"><fmt:message key="pro_bar_supplier_type"/></td>
          <td class="current"><fmt:message key="pro_bar_supplier_info"/></td>
          <td class="future"><fmt:message key="pro_bar_due_diligence"/></td>
     </tr>
</table>And the language file looks like:
pro_bar_requester=Requester
pro_bar_coi=Conflict of Interest
pro_bar_supplier_type=Supplier Type
pro_bar_supplier_info=Supplier Info
pro_bar_due_diligence=Due DiligenceHTH,
-Kevin

Difference between JSTL and JSF

Hi
I am little bit confuse between JSTL and JSF. can one tell me what is difference between JSTL and JSF ?
Thanks & regards,
Ben

from suns site
The JavaServer Pages Standard Tag Library (JSTL) encapsulates as simple tags the core functionality common to many Web applications. JSTL has support for common, structural tasks such as iteration and conditionals, tags for manipulating XML documents, internationalization tags, and SQL tags.
http://java.sun.com/javaee/javaserverfaces/overview.html

Sun JSF 1.1 or MyFaces Custom Validator Messages.

Hello i must use JSF 1.1 version for some old project. The problem is that NOW i must use localization and internationalization API to make it "good" in my own language - Bulgarian ( Cyrilic language)
The problem is that input components for 1.1 doesnt have attribute "label" i have defined in my resource bundle file the keys for standart validators such as this for example:
javax.faces.component.UIInput.REQUIRED={0} \u041F\u043E\u043B\u0435\u0442\u043E \u0435 \u0437\u0430\u0434\u044A\u043B\u0436\u0438\u0442\u0435\u043B\u043D\u043E
but the {0} parameter is aways - null ( and is not showed ) or is equal to the ID of the component which is English (ASCII) and it is not usable .. becouse it is ugly .
Can i make not so user friendly think like label but Something ?
can i pass some value to the validator ? ( which can be unicode )
Message was edited by:
JOKe

part of faces-config.xml:
<application>
     <message-bundle>com....resources.Messages</message-bundle>
     <locale-config>
          <default-locale>de_DE</locale-locale>
          <supported-locale>en_GB</supported-locale>
     </locale-config>
</application>This works for us.

Internationalization in JSF

Similar Messages

Maybe you are looking for