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.
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-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).
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.
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.
Globalization information can be passed to the Process Engine Web Service in the SOAP header. For more information, see Creating the Globalization Header .
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.