I was asked recently about how to send Workflow Notifications in different languages, dependent on the language preference of the recipient, so here’s my response in more detail.
Firstly, we need to understand how Workflow determines which language to use. The default language will be American (US), since this is the “primary” language that Oracle uses. For notifications, the Workflow Engine will look at the user preferences, and if they aren’t set, the global Workflow preferences – if the notification has not been installed in that language, then the system falls back to the default and uses American again.
Once you have the text converted into a different language, then you need to include them in the Workflow definition – I’m going to assume that you already have the translated text, so will skip my attempt to translate from one language to another!
The supported method for doing this is as follows. Firstly, change the NLS_LANG environment variable for your Workflow Builder machine:
- Run regedit to edit the registry
- Locate the NLS_LANG setting for the Oracle Workflow Home under HKEY_LOCAL_MACHINE/SOFTWARE/ORACLE
- Change the value to the new language, in the format LANGUAGE_TERRITORY.CHARSET, e.g.
Once you have changed the language, start Workflow Builder and create a new version of the Workflow definition which includes the translated text. You can translate as much or as little as you wish – message subjects and bodies as well as the display name for any object can be translated as necessary.
With the saved definition containing your translations, you can now save that version to the database using either the Workflow Builder or the command line Workflow Definitions Loader utility. Again, if you are using the Workflow Definitions Loader, you MUST change the NLS_LANG setting to make sure that the right language is loaded. This time, you should change the NLS_LANG setting to the following format:
Note that there is no need to include the language in the setting, because that is stored in the .wft file definition – however the leading underscore MUST be included. If you have defined the translations using a UTF8 character set, then you can set the NLS_LANG to just
and then load the definition.
That is the only supported method of loading a translation for Workflow into the database, but there is a much simpler way, albeit one which has marginally more risk.
For Notifications, the message body and subject are all defined in the WF_MESSAGES_TL table within the Workflow schema. When you deploy a translated definition to the database, any existing records are updated in the table, and any missing records are created as necessary. So, as a quick and simple way of deploying a translation, you could just insert or update WF_MESSAGES_TL directly with the translated text.
There are three main downsides that I can think of with this approach, however. Firstly, there are support issues if there was a problem – since you are not using the supported mechanism that Oracle provides, then I’d be astounded if Oracle Support will help if there are any later issues.
Secondly, there is no source controlled file which contains the translations – if you have defined a flat file, then you can version control the change, but this approach does not involve different Workflow files, so there is nothing from a Workflow perspective to version control.
Finally, if there are any changes to be made in the future, I would find it easier to change a Workflow definition than to have to change a SQL script which did the create / update of the translated record. That might be a minor point, but is one which is worth considering – how will someone maintain these changes in the future?
The main upside to these issues, however, is that there is no need to make a change to the registry to force the different language. This is a significant upside to the approach 🙂