About this task
The toolkit manages National Language Support (NLS) using
a special hidden field named "dse_locale". This field contains an
string (such as "en_US") representing the locale that the toolkit
uses. When the toolkit starts, the locale in the request sets the
locale for the toolkit. If any subsequent requests contain the dse_locale
hidden field, the toolkit replaces the current locale with the one
in the request.
The locale is per session. The dse_locale field
is used by the infrastructure to render both translated error messages
received during the validation process (the validators associated
with the typed data elements leave key messages inside the ErrorInfo
objects associated with each data element) and translated messages
configured in the corresponding JSP tags.
To change the locale,
use the JSP input shown in the following example:
<INPUT type=hidden name=dse_locale value=en_US>
See
the following in the HTML Sample Application for an example of how
NLS works with cross-validation and static messages:
- <dse:add file="htmlsample" /> in accountinquiry.jsp.
This tag specifies that the file htmlsample_xx_YY.properties (where
xx_YY is the locale that has been set by the application) is to be
used to translate the messages from this JSP.
- <dse:label text="Account_Summary" /> in accountinquiry.jsp
· Account_Summary entry in the htmlsample_xx_YY.properties files.
The htmlsample_en_US.properties translates this key to "Account Summary,"
and the htmlsample_es_ES.properties file translates it to "Extracto
de cuentas."
- "The_source_account_and_the" message in the xValidate
method of the AccountTransferXVal class. This class uses key cross-validation
messages that are translated by the JSP tags using the file that was
specified in the JSP.
- "The_source_account_and_the" entry in htmlsample_xx_YY.properties
files. The htmlsample_en_US.properties files translates this entry
as "The source account and the target account MUST not be the same."
The following shows how NLS works with single data field
validation messages:
- public Object validateForType(Object toValidate, PropertyDescription
descriptor, com.ibm.btt.base.Hashtable parameters) throws DSETypeException in
com.ibm.btt.base.types.ext.DateValidator. This method performs syntactic
field validation. Its messages are translated in the typesext_xx_YY.properties
files.
- public void validate(String fullyQualifiedName, com.ibm.btt.base.DataField
df, com.ibm.btt.base.Context ctxt) throws com.ibm.btt.base.types.DSETypeException method
in AccountTransferXVal class. This method performs semantic field
validation. Its messages are translated in the typesext_xx_YY.properties
files.
- typesext_xx_YY.properties files in dsetde.jar (TypedDataExtensions
component) and updated typesext_xx_YY.properties files in the sample
code. When creating an application, you should extract the files from
the JAR, build your own by adding new messages as necessary, and locate
them in the classpath.
The following shows how the user selects the language:
- serverData.languages collection in dsedata.xml
- <dse:combo dataName="dse_locale" dataNameForList="languages"
value="locale" item="name"/> in signin.jsp