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