IBM FileNet P8, Version 5.2.1            

Globalization

Your applications can display user-authored names (such as step responses, queue, roster, and field names) according to the user's current locale. At run time, the application retrieves the browser locale and calls VWSession.setLocale. The corresponding translation file (XLIFF file) is loaded from the workflow system database. (For information about creating these files, see Create an XLIFF File). When the application retrieves information from Process Java™ API objects, it uses the authored names of the objects as keys to retrieve the translated strings. These translated strings come from the XLIFF file. 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 is performed by the Process Java API.

No globalization of strings is performed by design-time applets such as Process Designer.

Methods accept the translated strings and look up the authored strings before the methods perform an RPC to the workflow system. For example, when the user wants to display the contents of a queue, VWSession.getQueue accepts the translated queue name and makes the corresponding RPC by using the authored queue name.

The specified strings might have the same value as an authored string. In these cases, the API attempts to look up the authored string by using the specified (possibly translated) string first. If the corresponding string value is not found, then the API assumes that 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, persist the authored strings. Otherwise, the Process Java API might not be able to look up the translated strings. For example, suppose that the translated queue names are persisted for a French locale and later referenced by another user with a German locale. Because the lookup is for a German locale, the API is not able to find the corresponding authored versions of the persisted strings.

Query Requirements

Query-related methods (such as VWQueue.createQuery) require that client applications supply authored strings for query parameters. Query performance is degraded if translation of localized strings to authored strings is necessary. In these cases, the user must enter any query criteria based on the locale that is used to author the data. Examples of query criteria include filter, minimum and maximum values, and substitution variables. At run time, the XML generated by the Process Java API contains the translated strings instead of the authored strings (assuming the locale is set).

Note: Several classes have methods that also expose the authored name (such as VWQueueElement.getAuthoredStepName). This information is also included in the generated XML.

Exceptions

Some exceptions and error messages are loaded (statically) from a resource bundle file. This resource bundle corresponds to the locale in use when the load operation occurred. If the resource bundle file is not available, the "en_us" locale is used.

Email Notifications

Client applications can allow the user to select a preferred locale from the set of available locales that are registered on the workflow system. The selection is saved in their user preferences and used as the locale for email notifications. See VWUserInfo.setPreferredLocale.

Process Engine Web Service

Globalization information can be passed to the Process Engine Web Service in the SOAP header. For more information, see Creating the Globalization Header .

Process Engine REST Service

Use the Accept-Language HTTP Request Header field to specify the languages that are preferred as a response to a request. For more information, see Specifying a Locale in Process Engine Web Service Reference.



Last updated: October 2015
pe_localization.htm

© Copyright IBM Corporation 2015.