If you receive an error when running the project, revisit the setup instructions, which describe how to prepare the database and establish connectivity between the IDE, GlassFish, and MySQL.

Note that the wizard provides a description for the selected file type:

Note that the new messages.properties file name does not have a language code appended to it, as was previously described. This is because this file will be used as the default resource bundle. The default resource bundle is applied when the Java runtime environment does not find a direct match for the requested locale.

Recall that one of the implementation details outlined above states that "if the browser’s preferred language is neither English nor Czech, the site displays text in English." Therefore, the values that we apply to the messages.properties file will be in English.

Comments are added using a number sign (‘#’). Also, because the fruit & veg category name contains spaces, it is necessary to escape the space characters using a backslash (‘\’) in order to apply the name as a resource bundle key.

We are now finished with the default resource bundle for the application’s welcome page. Let’s continue by creating resource bundles for the customer-specified languages.

A locale can be defined by both a language and a geographic region. The optional country code which can be used to specify the region can be applied to define formatting for dates, time, numbers, and currency. For more information, see the technical article, Understanding Locale in the Java Platform.

Press Shift-Esc to maximize the window in the IDE.

Note that when you add a new locale using the Customizer dialog, as you did for English and Czech in the previous steps, the keys and values of the default resource bundle are copied to the new locale.

You can also add a comment to each key-value pair. Any text you enter into the Comment field in the Properties editor is added to the resource bundle text file above the key-value pair as a comment (i.e., following a ‘#’ sign).

We now have the following resource bundles defined:

You might assume that if the default bundle is in English, then there is no need to create a resource bundle explicitly for English. However, consider the following scenario: a client browser’s list of preferred languages includes both Czech and English, with English taking precedence over Czech. If the application doesn’t provide a resource bundle for English but does for Czech, pages sent to that browser will be in Czech (since a Czech bundle was defined). This is clearly not the desired behavior for that browser.

The purpose of this step is to inform JSTL’s format (i.e., `fmt`) tag library where it can locate any resource bundles existing in the application. You accomplish this by instructing the application to create a `LocalizationContext` using the existing resource bundles. This can be done by setting a context parameter in the application’s web.xml deployment descriptor.

The topic of setting context parameters is also covered in Connecting the Application to the Database.

The LocalizationContext class belongs to the javax.servlet.jsp.jstl.fmt package. You can verify this by viewing the JSTL 1.1 API Reference online.

In order to apply the localized text of resource bundles to your web pages, you reference the keys from the key-value pairs you created. You can reference the keys using JSTL’s <fmt:message> tags.

Note: Here you add the tag library declaration to the top of the index.jsp file. However, when you begin using <fmt> tags elsewhere in the project, it may make more sense to remove the tag library declaration from individual page views, and add it to the header (header.jspf) file. This practice is adopted in snapshot 9 (and later snapshots).

You’ve now completed the tasks necessary for providing bilingual support for the application’s welcome page. The following step demonstrates how to test the language support in your browser.

You could theoretically test for the following scenarios involving the application’s supported languages, as well as an unsupported language (e.g., Korean):

Rather than stepping through all 16 scenarios, we’ll demonstrate how to examine scenario 3 above, in which the browser’s preferred language is Czech, using the Firefox browser.

This markup implements the language toggle’s appearance when English is the displayed language. In other words, the toggle provides a link allowing the user to select the Czech (i.e., ‘česky’) option. The link is used to send a request for chooseLanguage, and creates a query string (?language=cs) that specifies the requested language code.

Note: Recall that in Unit 5, Preparing the Page Views and Controller Servlet, you set the ControllerServlet to handle the /chooseLanguage URL pattern.

Snapshot 8 includes the jQuery JavaScript library and takes advantage of various UI effects to enhance the appearance and behavior of the website. Aside from a jQuery plugin for client-side validation (discussed in the previous tutorial unit), the snapshot implements an easing effect for category headings in the welcome page, as well as for category buttons in the category page. Configuration is included in header.jspf of the project snapshot. Rounded corners are implemented using CSS3’s border-radius property (applied in affablebean.css).

Currently, the language toggle appears as in the above image regardless of what language the page displays in. In the next step, you integrate JSTL logic into the toggle so that it renders according to the language displayed on the page.

In the above implementation, you rely on conditional tags from JSTL’s core tag library to display the left and right portions of the toggle according to the language used by the request locale. What is the "language used by the request locale"? When a request is made, the browser passes a list of preferred locales in the Accept-Language HTTP header. The Java runtime environment on the server reads the list and determines the best match based on the locales defined by the application’s resource bundles. This match is then recorded in the ServletRequest object, and can be accessed using the getLocale method. For example, you could access the preferred locale from a servlet with the following statement.

You can use the IDE’s HTTP Monitor (Window > Debugging > HTTP Server Monitor) to examine HTTP headers for client requests. In order to use the HTTP Monitor, you need to first activate it for the server you are using. Unit 8, Managing Sessions provides a demonstration under the sub-section, Examining Client-Server Communication with the HTTP Monitor.

To determine the language of the preferred locale, you use the Locale class' getLanguage method. Again, from a servlet you could access the language of the client request’s preferred locale with the following.

Returning to the code you just added to the header.jspf fragment, you utilize the pageContext.request implicit object to access the ServletRequest for the given client request. Using dot notation, you then proceed to call the same methods as you would from a servlet. In the above example, accessing the "language used by the request locale" is as simple as:

Note: The above implementation uses <c:url> tags to set up the toggle link. This is done in order to properly encode the request URL in the event that URL rewriting is used as a means for session tracking. Unit 8, Managing Sessions provides a brief explanation of how the <c:url> tags can be used.

If your browser’s preferred language is set to Czech, you can note the following: * The test that we introduced in the previous step indicates that ‘cs’ is the preferred language. * Czech text is displayed in the page. * The language toggle provides a link enabling the user to select English.

Now that the toggle is in place and it appears according to the language displayed in the page, let’s continue by adding code to the ControllerServlet that handles the request sent when a user clicks the link in the language toggle.

As indicated in the current language toggle implementation from step 4 above, the requested URL with query string looks as follows:

Our goal is to register the language choice, and then display both the page view and language toggle based on the chosen language. We can accomplish this by extracting the language parameter from the query string and creating a session-scoped language attribute that remembers the language selected by the user. Then we’ll return to the header.jspf fragment and apply the `<fmt:setLocale>` tag to set the page language based on the user’s choice. With the <fmt:setLocale> tag we can manually switch the language used in the page display. We’ll also modify the language toggle so that if the language attribute has been set, the toggle’s appearance is determined according to the language attribute’s value.

Naturally, forwarding the user to the welcome page regardless of what page he or she is on is not an ideal way to handle the language toggle’s behavior. We’ll return to this matter in the next sub-section, Enable the Application to Keep Track of the Originating Page View. For the meantime however, this will allow us to examine the results of the current language toggle implementation when running the project.

Since the language variable is only created when the user clicks the link in the language toggle, you perform a test using `<c:if>` tags to determine whether the variable exists before attempting to set the language. When applying the <fmt:setLocale> tag, you set its scope to session as you want the user-selected language to take precedence for the remainder of his or her session on the website. Also, since this is the first time the fmt library is used in the header, you declare the tag library.

You can read the EL expression ${!empty language} as, "False if the language variable is null or an empty string." See the Java EE 5 Tutorial: Examples of EL Expressions for other available examples.

Enclose the current implementation within <c:choose> tags, and create logic similar to the current implementation in the event that the locale has been manually set. (Changes are displayed in bold.)

javax.servlet.jsp.jstl.fmt.locale.session is the string literal key for the Locale set by the <fmt:setLocale> tag. You can verify this by clicking in the editor’s left margin to set a breakpoint ( ) on the new test, then running the debugger ( ) on the project. When you click the toggle link to change languages in the browser, examine the Variables window (Alt-Shift-1; Ctrl-Shift-1 on Mac) when the debugger suspends on the breakpoint.

EL expressions presented in this tutorial primarily use dot (.) notation. The format depicted in the expression above is known as bracket ([]) notation whereby you enter the string literal key within quotes in order to extract the object’s value:

Numerous EL resolver classes exist for the purpose of resolving expressions. For example, when the above expression is encountered at runtime, the `ImplicitObjectResolver` first returns a Map that maps session-scoped attribute names to their values. (In the above image of the Variables window, you can verify that session attributes are maintained in a `ConcurrentHashMap`.) In order to resolve the remainder of the expression, the `MapELResolver` is used to get the value of the key named ‘javax.servlet.jsp.jstl.fmt.locale.session’.

For more information, refer to the Java EE 5 Tutorial: Unified Expression Language: Resolving Expressions.

In the above image, the server identifies Czech (cs) as the browser’s preferred language from the Accept-Language HTTP header. This is indicated from the first test. The page displays in Czech, and the language toggle enables the user to choose English. The second test remains blank as the <fmt:setLocale> tag has not yet been called.

When clicking the toggle link, the default Czech language is overridden by means of the <fmt:setLocale> tag implemented in the header.jspf file. Although the browser’s preferred language remains Czech, you see that the page now displays according to the new language made available by the language toggle.

Changing the language back to the browser’s preferred language works as expected, however note that the deciding factor is no longer the language detected from the Accept-Language HTTP header, but is the language specified from the <fmt:setLocale> tag.

One of the implementation details which you have agreed on with the Affable Bean staff is that when the language toggle is used to change the language, the user remains in the same page view. In our current implementation, the welcome page is returned whenever the language toggle is clicked. A more user-friendly approach would be to provide the application with a means of tracking the request page view, and forwarding the request to that page view when the language toggle link is clicked.

We can accomplish this by setting a session-scoped view attribute within each of the page views, then referencing this attribute in the ControllerServlet in order to determine where to forward the request. There are however several caveats to consider when dealing with the language toggle in the confirmation page. These are discussed and dealt with in steps 7-11 below.

Begin this exercise with snapshot 9 of the AffableBean project. This snapshot includes completed English and Czech resource bundles for all page views, all page views have been modified to use text from the resource bundles, and the language toggle is presented in a state corresponding to this point in the tutorial.

If you receive an error when running the project, revisit the setup instructions, which describe how to prepare the database and establish connectivity between the IDE, GlassFish, and MySQL.