Setting National Language Dynamically at Runtime

Setting National Language Dynamically at Runtime

WebClient Multi-Language Support


This document exemplifies the process to support multi-language in a WebClient dynamically via changes at run-time.

This process exemplifies the process to setup and configure an application that will support Multi-language with target languages English, Spanish, and French.

The end-user will be able to change the national language configuration at runtime and the web application will refresh the change to display fields’ labels and a button’s text in the target locale (language).

This document and example was prepared with PLEX 7.1, Java 7, Eclipse Luna Release (4.4.0), WebClient 1.8.2

A Local Model, WebTest, accompanies this document and a test function, impl name: TestGrid, is included to exemplify the development required for the dynamic change of language (locale).


To enable multi-language support add the following properties to the file:


In addition, there is another setting in that defines the default locale:


NOTE: In this example the default locale is English (en).

These settings will affect how WebClient generates elements such as labels and buttons’ text in the .wcli files therefore you will have to regenerate all your panel templates as described in the next steps.


To provide the resource files for each language (locale) supported by the application it is necessary to manually create a folder for each locale at the lowest level of your package.

For example, if the package name is “WebClientTest”, as in the accompanying Model for these instructions, this would be the location of the folders for each supported locale:


So the following folders have been created to support ENGLISH (en), SPANISH (es), and FRENC (fr) locales:

To generate the appropriate resource files it is necessary to change the PLEX configuration to the appropriate target language and then generate the source which is then copied to the corresponding src/res folder for each locale supported.


Perform the following process:

  1. For English set the FIELDS configuration to the BASE Language:
  2. Generate the function TestGrid. Don’t compile:
  3. Refresh the TestJava project to rebuild the templates:
  4. Then grab the .panelresource and .resource files just created and move to the appropriate RES folder for ENGLISH (Base) language: 
    Copy from:
  5. For French set the FIELDS configuration to the FRENCH Language:
  6. Generate the function TestGrid. Don’t compile.
  7. Refresh the TestJava project to rebuild the templates.
  8. Grab the .panelresource and .resource files just created and moved to the appropriate RES folder for FRENCH language:
    Copy from:
  9. For Spanish the FIELDS configuration is set to the SPANISH Language:
  10. Generate the function TestGrid. Don’t compile.
  11. Refresh the TestJava project to rebuild the templates.
  12. Grab the .panelresource and .resource files just created and moved to the appropriate RES folder for FRENCH language:
    Copy from:


There are two alternatives for changing the locale:

  1. Static
  2. Dynamic

For a static local change you need to change the following property on the file:


XX = Locale indicator such as EN (English), FR (French), and ES (Spanish)


Will switch the application’s local to Spanish.

For 2), dynamic changes, the above property can be switched via the use of the Source Code JAVAPI/SetRunOptionValue. The SetRunOptionValue Source Code is shipped with PLEX and allows chaning any runtime option at runtime.

To reflect the changes after a locale switch it is necessary to refresh the application’s page and the following source code can be used:

import com.adcaustin.webclient.*;
((IWebFunction) fnc).getWebPanel().setRefresh();

Example of an implementation with a dynamic locale change/page refresh can be found in the test function TestGrid, in the accompanying Test Model for this document, which includes a language radio-button field that triggers the ChangeLanguage logical event:

In the Action Diagram the functionality retrieves the language value which is assigned to the PropertyValue field.

This PropertyValue field and the PropertyKey = Locale.Language are used to set the WebClient run option value to set the locale, and finally the application’s page is refreshed with the suggested source code:

Another example, not found in the provided Model, can be found in the following image where the code to set the language takes place before the login process of an application. In this additional example, the language is obtained from the request (browser locale) then mapped to the Java Locale, and finally the runtime option (locale) is set.

Once the user has logged in the application knows his preferred language, from a User Database implemented on this system, so that the Locale can be switched to the one in the User Profile table:


To test the runtime use: http://localhost:8080/TestWeb/wc

Use the language radio control to set and change the locale

  1. By selecting English all labels and the button text are changed to English
  2. By selecting Spanish all labels and the button text are changed to Spanish:
  3. By selecting French all labels and the button text are changed to French:


  • In case you experience issues with Tomcat web server launch please see the section “WebClient Multi-Tomcat Installation Issues” on the WebClient Manual Website
  • Ensure you are using the appropriate Java Version for your version of Eclipse. For example, if you are using Eclipse Luna (4.4.0) you might be needing to use Java 7 which is installed on C:\Program Files\Java\jdk1.7.0_71\bin. NOTE: The version of Java used is specified with the full path to the Javaw.exe on Eclipse.INI

Invalid Java version to use with this workspace would display an error with Exit Code = 13 upon launching the workspace:

To specify the Javaw on Eclipse.INI:

  • The -vm option and its value (the path) must be on separate lines.
  • The value must be the full absolute path to the Java executable, not just to the Java home directory.
  • The -vm option must occur before the -vmargs option, since everything after -vmargs is passed directly to the JVM

Example of an Eclipse.ini modified to specify the Java executable:


C:\Program Files\Java\jdk1.7.0_71\bin\javaw.exe


  • There are limitations to the multi-language capabilities for the Dojo Presentation Language. Dojo has its own configuration to control the localization of controls, for example the one for DatePicker. The Dojo Locale setting defaults to the Browser Locale which is not the one expected when managing multi-language support as such browser locale would be different from the User Locale. A mechanism to get the current PLEX Java Locale, defined by the SetRunOption value, into the WebClient Javascript code would be needed to set the Dojo Configuration correctly. Such mechanism is beyond the scope of this document.
  • UTF-8 Format Support. UTF-8 is UTF-8 is a character encoding capable of encoding all possible characters, or code points, in Unicode and is needed in certain environment such as Linux to support foreign language encoding.
    It is important to note that there is a known limitation with PLEX where it cannot generate UTF-8 files, despite the specification on Gen&Bld > Options > System Definitions > Java Build > Java Encoding, therefore a conversion process needs to take place after the files are generated.
    In Eclipse, for setting the charset or file encoding in the whole project you can make use of the Java Project Properties > Resource tab

Note that this configuration would only work for the development environment.

Specify the target web server, for example Tomcat, just select export to WAR file on the Web Project and specify such option:

In addition, you can also try the following setting on:


In such file include the following:

export CATALINA_OPTS=-Dfile.encoding=CP1252

To enable UTF-8 although this has not worked consistently therefore an alternative is to convert the entire RES folder where the .panelresource files are located massively to UTF-8 before the Eclipse Build to have the final files in UTF-8 before releasing to Linux. This can be achieved with a utility like TextCrawler ( or ICONV ( The SRC folder includes the RES folder and also the java sources. The reason for converting all is that captions are stored as part of the java code, not the panelresources, so they need to be converted too.

Also, to change the encoding for Tomcat in general, in your production environment, you can do the following: On Windows Edit the file $TOMCAT_HOME\bin\startup.bat and insert or alter the following line, substituting for the desired values: set CATALINA_OPTS=-Dfile.encoding=CP1252. The problem might be that this setting would be global and could affect other applications using Tomcat so use it just if you are certain this global setting is appropriate.

Finally, in WebClient the filenames can be encoded to prevent issues saving files with unsupported characters such as with foreign languages. Check the Additional Notes on