Process of Displaying Text Strings

This topic lists the sequence of events for displaying text strings in Workspace.

1. The language is established at login using the selection specified in Options:
   

   Or it can be changed dynamically using the Language field on the toolbar:

   

   The selections that are available from both of the Language field lists are determined by the key attributes in all of the general resource files (that is, the locale.ll.xml files).

   Prior to any language packs being installed, or any custom localization being performed, the only key attributes are key=”en_US” in the default locale.xml file and the key=”en_GB” in the locale.en_GB.xml file. This results in “English (United States)” and “English (United Kingdom)” appearing in the Language fields:

   

   If, however, you perform the steps provided here to localize your application, there will be additional key attributes in the resource files. For every key attribute, an additional language (possibly country specific) is shown in the Language fields. For example, if the following key attributes are found in the resource files:

   • key=”en_US”
   • key=”en_GB”
   • key=”es”
   • key=”es_EX”
   • key=”es_MX”

     ... the Language fields will contain the following selections:

     

     Note: The first time Workspace is started (that is, prior to determining what is specified in Options), the language that is specified in the browser is used.
2. For each text string that the application needs to display, it accesses the appropriate resource file based on the selected language.
   1. If the text string is displayed somewhere in the application other than in the event view list or Event Viewer, it gets the string from the resource file whose name includes the appropriate language code. The following illustrates this using Spanish and Spanish (Mexico) as an example:
      • If the selected language is just “Spanish”, it uses the strings under key=”es” in the locale.es.xml file. If the string it is looking for (based on a jsxid attribute) cannot be found in this file, it “falls back” to the default locale.xml file and uses the string from that file.
      • If the selected language is Spanish (Mexico), it uses the strings under key=”es_MX” in the locale.es.xml file. If the string it is looking for (based on a jsxid attribute) cannot be found under this key, it “falls back” to using the string under key=”es” in the locale.es.xml file. And if it cannot be found under key=”es” of that file, it again falls back to the default locale.xml file and uses the string from that file.

        The following illustrates this. If it is looking for the text string for jsxid=”txtOpen”, and the language selected is Spanish (Mexico), it will use the string under key=”es_MX”.

        <data jsxnamespace="propsbundle"
            <locale key="es">
              <!-- DEFAULT LANGUAGE RECORD ELEMENTS HERE -->
              ...
              <record jsxid="txtClose" jsxtext="Cierre"/>
              <record jsxid="txtOpen" jsxtext="Abierto"/>
              ...
            </locale>      
            <locale key="es_ES">
              <record jsxid="txtOpen" jsxtext="override value for Spain"/> 
            </locale>
            <locale key="es_MX">
              <record jsxid="txtOpen" jsxtext="override value for Mexico"/>
            </locale> 
        </data>

        An exception to the process described above for “general” resource files is when “English (United States)” is selected. The default locale.xml file is used in this case—it does NOT have a key=”en” like all of the other general resource files.

   2. If the text string is in the event view list or the Event Viewer, it gets the string from the appropriately named event resource file. The following illustrates this using Spanish and Spanish (Mexico) as an example:
      • If the selected language is just “Spanish”, it uses the strings in the eventLocale.es.xml file. If the string it is looking for (based on an id attribute) cannot be found in this file, it “falls back” to the default eventLocale.xml file and uses the string from that file.
      • If the selected language is Spanish (Mexico), it uses the strings in the eventLocale.es_MX.xml file. If the string it is looking for (based on an id attribute) cannot be found in this file, it “falls back” to the eventLocale.es.xml file. And if it cannot be found in that file, it again falls back to the default eventLocale.xml file and uses the string from that file.

        Note that the naming convention for the English (United States) event resource file (eventLocale.xml) is an exception—this file does not include “en” in the name like the other event resource files. However, if you add country-specific English translations, event resource files with ll_CC in the name must exist, for example, eventLocale.en_GB for English (United Kingdom).