SDX and multilingualism

In the configuration file (application.xconf), The superior element sdx:application must have an attributexml:lang. The value of this attribute can be used by SDX to identify the display language. This value can be considered as the default language of the application; for a single language application this attribute is usually enough to indicate the language.

Web applications which are built with SDX contain user services for providing Web pages. Even when there is no formal identification, SDX consider a specific user, the anonymoususer; no language is linked to that user, but it is an exception. All other users have an associated language, and this language can be used to determine the display language.

In the SDX interface for user creation, a language can be specified for a user. Applications with their own interface of user management can link a language and a method, SDX will still use that language to specify the display language.

In an XSP page, a language can be directly specified and it is possible for SDX to use that language for the display language. This language specification must be done with an xml:lang attribute of the sdx:page element or its parent element xsp:page. For example:

<xsp:page>
  <sdx:page xml:lang="es">
  ...
  </sdx:page>
</xsp:page>

The SDX API uses a generic concept of parameters and proposes various ways of specifying those parameters in an XSP page. Further details can be found in the documentation on the concept of parameters, but we will illustrate their use for the language.

SDX parameters must have a name; for the language, the parameter name is lang. Then, SDX offers five ways to specify a value of a parameter, which are, ordered by priority: a Java variable which is not null and is definied in the XSP; a value which comes from an HTTP request parameter (thus from the URL); a value which is stocked in a session object on the server; an explicit value in the XSP page, finally a default value in SDX. We must also mention that for the language, there is no default value in SDX; this feature is not important, since the application language (defined in the application.xconf) is considered as the default value. We shall also mention that using an explicit value for a parameter does not have any advantage compared with using the xml:lang attribute in the XSP page, as mentioned above.

This parameter code must be associated to the sdx:page element. The following example shows various ways to do this:

<!-- Valeur explicite -->
<sdx:page lang="fr">

<!-- Value which comes from the session object whose key is "language" -->
<sdx:page langSession="language">

<!-- Value which come from an HTTP parameter "l" (for example the test.xsp?l=fr URL) -->
<sdx:page langParam="l">

<!-- Value which comes from a Java variable which has been previously defined -->
<xsp:logic>
  String l = "fr";
</xsp:logic>
<sdx:page langString="l">

Thos examples all use the attributes method to identify a parameter. But SDX offers a second method, which is sub-elements sdx:parameter to specify parameters. It is therefore possible to replace the third example above by the following code:

<sdx:page>
  <sdx:parameter name="lang" valueParam="l"/>

This method of parameters is very flexible, and it is necessary to create genuine dynamic and multilingual Web applications. For example, it is possible to add the l parameter to all interfaces and to give them the language value, and to use the langParam="l" attribute in the XSP page, so that the display language always has a suitable value.

However, this approach has a drawback: the developer must always include the l parameter in the hypertextual links, which may lead to mistakes. As a solution, it is possible to stock that value in an object session, SDX can then use it. It is only necessary to use this in the XSP pages:

<sdx:page langSession="l" langParam="l">

Specifying both indications is not a problem, on the contrary, since SDX defines a priority: the URL parameter (langParam attribute is a priority on the session object, but hat priority is only considered if there is indeed that parameter in the URL. Moreover, if the URL contains that parameter, then SDX uses it and keeps its value as a session object, because of the langSession attribute with the same value as the one of the langParam attribute.

This feature of SDX parameters is probably the one which leads to the best flexibility and ease of use for language management. This can be illustrated with an example. Assuming that the above code belongs to an XSP page called index.xsp. This page is successively called with various parameter values, and let's consider the way the display language is specified:

This approach allows the developer to specify a URL parameter only when he wants to change the display language. It is also possible to add a langString attribute which behaves the same way as langParam, but with a value defined by a Java variable and with an even higher priority. This allows to specify the language according to a logic which is more precise than the one entailed by simple URL parameter values, if necessary.

<?xml version="1.0" encoding="ISO-8859-1"?>
<french useStopWords="true" keepAccents="false">
   <stopWords>
     <stopWord>le</stopWord>
     <stopWord>la</stopWord>
     <stopWord>les</stopWord>
     ...
  </stopWords>
</french>

Two attributes allow to directly specify which word analyser must be used: analyzerClass and analyzerConf. Those attributes can be associated to the sdx:field element, and they identify the word analyser of the given field, otherwise they can be associated to the sdx:fieldList element, they identify the default word analyser for the document base.

The analyzerClass attribute indicates the class to be used as the analyser; such as described above, this class must extend the fr.gouv.culture.sdx.search.lucene.analysis.Analyzer class and and it must obsiously be included in the Java CLASSPATH.

The analyzerConf attribute indicates the location the configuration file for the word analyser. The attribute value is a URL, absolute or relative to the application.xconf file. If this attribute is not defined, the default configuration of the analyser is used. This attribute can also specify a configuration file if the word analyser is specified indirectly.

A word analyser may also be specified indirectly, which means by precising the language of the field content or of all document base fields. If the xml:lang and variant attributes are used with the elements sdx:field (for a particular field) or sdx:fieldList (as default value for all document base fields), SDX will attempt to find a suitable word analyser for this language.

The method used by SDX to find this analyser can be demonstrated through an example. Assuming the following definition :

<sdx:field ... xml:lang="fr-CA" variant="qc"/>

The algorythme will be:

If a xml:lang attribute is used together with a analyzerClass attribute, the latter is used to find the word analyser. The direct method is prioritary on the indirect one.

When no analyser is specified for a field or for a document base, SDX uses the fr.gouv.culture.sdx.search.lucene.analysis.DefaultAnalyzer analyser, which is a word analyser for the English language. This analyser is also used if a field indirectly declares an analyser that is not available with SDX.