Your applications can display user-authored names (such as step responses, queue, roster, and field names) according to the user's current locale. At runtime, the application retrieves the browser locale and calls VWSession.setLocale. This loads the corresponding translation file (XLIFF file) located in the "PEAuthoredNames.jar" file (see Create an XLIFF File for instructions in creating these files). As the application retrieves information from Process Engine API objects, the translated strings are retrieved from the XLIFF file using the authored names of the objects as the key. If a translated string is not available, authored names are returned by the calling methods.
Note: If the locale is not set, no lookup of translated strings will be performed by the Process Engine API.
No localization of strings is performed by design-time applets (such as Process Designer and Configuration Console).
Methods will accept the translated strings and look up the authored strings before performing an RPC to the Process Engine server. For example, when the user wants to display the contents of a queue, VWSession.getQueue will accept the translated queue name and make the corresponding RPC using the authored queue name.
In cases where the specified strings have the same value as an authored string, the API attempts to look up the authored string using the specified (possibly translated) string first. If the corresponding string value is not found, then the API will assume the string is an authored string.
If translated strings (such as queue names) are persisted by client applications, and later used by a calling method, it is the authored strings that should be persisted; otherwise, the Process Engine API may not be able to look up the translated strings. For example, if translated queue names are persisted for a French locale, and later referenced by another user having a German locale, the API will not be able to find the corresponding authored versions of the persisted strings, because the lookup will be performed using the German locale.
Query-related methods (such as VWQueue.createQuery) require that client applications supply authored strings for query parameters. Query performance would be significantly degraded if translation of localized strings to authored strings was necessary. In these cases, the user must enter any query criteria (such as filter, min/max values, and substitution variables) based on the locale used to author the data. At runtime, the XML generated by the Process Engine API will contain the translated strings instead of the authored strings (assuming the locale has been set).
Note: Several classes have methods that also expose the authored name (such as VWQueueElement.getAuthoredStepName). This information will also be included in the generated XML.
Exceptions and error messages that are retrieved from a resource bundle file are loaded (statically) from the resource bundle that corresponds to the locale in use when the load operation . If the resource bundle file is not available, the "en_us" locale is used.
Client applications can allow the user to select a preferred locale from the set of available locales that are registered on the Process Engine server. The selection is saved in their user preferences and used as the locale for email notifications. See VWUserInfo.setPreferredLocale.
Localization information can be passed to the Process Engine Web Service in the SOAP header, see Specifying a Locale for more information.
Use the Accept-Language HTTP Request Header field to specify the languages that are preferred as a response to a request. See Specifying a Locale for more information.