This chapter describes how to work with languages and internationalization in Demantra.
This chapter covers the following topics:
Oracle Demantra is available in multiple languages and supports multiple languages in a single installation. By default, English is the default base system language. However you can select any of the supported languages to be the base system language when installing or upgrading the application. You can also choose to install one or more additional languages. For a list of all available languages, see the Oracle Demantra Installation Guide.
Important: For non-ASCII languages, see the note regarding text editor capability in the section Logging Messages of the Application Server.
The locale settings of the client machine determines the default language of the Languages dropdown.. (If that language is not supported or installed, then the base system language will be the default.) If cookies are enabled in the user's browser, then this will determine the default language for subsequent logins. All seeded content is available in the login language. Other content, which was added after application installation (such as series, levels, and members), must be translated manually before it is available in the login language. Alternately, users may be integrated from EBS, and in this case, the default language is inherited from the user integration and passed on using the single sign-on mechanism. For user's defined indirectly via EBS integration, the language of the EBS instance will be passed to Demantra. Workflow messages, such as those that appear in the 'My Tasks' section in the Demantra Local Application and automated emails, will also be displayed in that language.
Oracle recommends that users define all public content - for example public worksheets, series and workflows– in the base system language and then either an administrator or translation expert translate those objects into other supported languages as required. For more information on translating these objects, see Translating Content into Different Languages.
These application objects appear in the language selected by the user:
Series
Series groups
Series lookup tables
Levels
Level members
Level attributes
Level methods
Worksheets
Workflows
Schema names
Step names
Messages (in User, Group, Exception and Selection steps)
Comments (in BLE steps)
Subject/Messages (in Email steps)
Schema group names
Schema group descriptions
These platform data appear in the language selected by the user:
Button labels
Tool tips
Object descriptions
Menu items
Error messages
Online help (user guides only; all other documentation is available only in US English)
You can edit worksheet data using the offline worksheet mechanism; however, you cannot edit its definition, for example, the displayed series, the applied filters, and the types of graphs.
When you take a worksheet offline, you see its objects, for example, series, levels, and drop-down menus in the language selected by the user who exported it. For more information about working offline, see the Oracle Demantra User Guide.
When you export a worksheet to Microsoft Excel, the data appears in the language selected by the user who exported it.
Oracle recommends that you import item master data in the base system language. This includes both regular levels, for example, item and location, and general levels, for example, promotions, supply plans, and bills of material. However, there is no requirement that all of your item master data must be in one language.
Most Business Modeler and Demand Planner fields work with non-ASCII characters, for example, characters in languages, Chinese, Japanese, Korean and Russian. However, some are only available for ASCII characters. Oracle Demantra indicates the fields that are only available for ASCII input by red field titles.
Oracle Demantra derives the default date display format from the operating system locale. Locale refers to the location where your instance conducts business. For example, you set the locale in Microsoft Windows in the Control Panel > Regional and Language Settings.
The Display Format setting in the Configure Measures window (in Business Modeler) displays the same number of digits per date element across locales. However, the order of date elements and the separator will vary by locale.
For example, you operate in a French locale. This table shows how the Business Modeler choice maps to the Web display.
Business Modeler Format | Localized Format |
---|---|
MM/dd/yyyy | dd.MM.yyyy |
MM/dd/yy | dd.MM.yy |
MM-dd-yyyy | dd.MM.yyyy |
dd.MM.yyyy | dd.MM.yyyy |
dd.MM.yy | dd.MM.yy |
dd/MM/yyyy | dd.MM.yyyy |
dd/MM/yy | dd.MM.yy |
E, MMM. dd yyyy | E, MMM. dd yyyy |
E MM/dd/yyyy | E MM.dd.yyyy |
E MM-dd-yyyy | E MM.dd.yyyy |
E dd/MM/yyyy | E dd.MM.yyyy |
E dd.MM.yyyy | E dd.MM.yyyy |
MM-dd-yy | dd.MM.yy |
The base system language does not typically have an effect on the display of dates, times and numbers.
To refine your date display, use Worksheet Designer, navigate to region Time, click Advanced, and modify the advanced time settings.
Oracle Demantra derives the default number and currency display format from the operating system locale.
The Business Modeler series display format for a number provides a representation of how it is displayed. For example, it provides the standard display formats to reflect the number of decimal places and uses this to determine the need for radix points and thousand separators. Locale controls the delimiters. If a series display property is #,####.##, it displays in:
North American locales as 1, 234.56
European locales as either 1.234,56 or 1 234,56
However, determining the currency from the locale may not always be accurate, especially if you report in a currency different from the operating system locale. For example:
Your default language may be used in multiple areas with different currencies. You have an instance using language Chinese Simplified, but you could report currency in, for example, China Yuan Renminbi (CNY) or Singapore Dollars (SGD).
If you have a default language that corresponds to one currency, you may want to report it in a different currency. Your language is French (Canada) that corresponds to currency Canadian Dollars (CAD), however, you want to report in United States Dollars (USD)
If your business requires reporting in multiple currencies or a currency different from the locale, Oracle recommends that you:
Use series titles as a means of clarifying currency, for example, Budget (USD) instead of Budget $.
Display the currency without a currency indicator or symbol, for example, Budget (USD) = 2,000 instead of Budget = $2,000
In order to correctly display customer-specific strings in non-English languages, the operating system client locale, and several database parameters, must be set appropriately. These user-defined strings may include worksheet names, workflow names and messages, and strings for Dynamic Open Link compatibility.
Ensure the following parameters as set as listed below:
NLS_LENGTH_SEMANTICS = CHAR
NLS_CHARACTERSET = AL32UTF8
NLS_LANG = language_territory.characterset
For details about configuring Oracle to support Globalization, see Oracle Database Installation Guide for Microsoft Windows or the Oracle Database Globalization Support Guide.
Workflows display in the user's language as defined in the user's Business Modeler profile.
Oracle recommends that all public or shared content (series, worksheets, workflows, methods, etc) be defined in the base system language and then be translated into other supported languages as required. You can import translated content into Demantra by using:
The translation API (MLS_INTEG_IMPORT)
A Web-based tool known as the Translation Utility
"For more information about the translation API, see Loading Translations. For details about the Web-based tool, see Using the Translation Utility.
Note: Demantra supports multilingual item master only when deployed as a standalone solution. That is, the same SKU can have multiple translated descriptions. This feature is not supported when Demantra is deployed as an integral part of the Oracle VCP planning server. All imports and exports from a Demantra MLS deployed solution are exported in the system base language.
Demantra provides the following procedures that can be used to import translated content:
MLS_INTEG_IMPORT.MLS_DICT_LOAD for bulk loading translations, via a populated dictionary staging table.
MLS_INTEG_IMPORT.TRANSLATION_API for individual translations.
Use the MLS_INTEG_IMPORT.MLS_DICT_LOAD procedure to import all translated content that has been entered in the Demantra dictionary staging table (I18N_DICTIONARY_STAGING) to the dictionary data table (I18N_DATA_DICTIONARY). This procedure can be executed:
Automatically, by running the seeded Language Translations Import workflow
Manually, from the command line (SQL> MLS_INTEG_IMPORT.MLS_DICT_LOAD)
Before running this procedure, you must first load translation data into the I18N_DICTIONARY_STAGING dictionary staging table. This table must have the following entries:
Column Name | Description |
LOCALE_ID | Language indicator, which may be one of the following values:
|
OBJECT_TYPE_CODE | Object type, which may be one of the following values:
|
ATTRIBUTE_TYPE_CODE | Attribute of an object, for objects that have secondary details, and may be one of the following values:
|
PARENT_OBJECT_NAME | Parent of the object. For example, LEVEL is parent of members. This is the actual name of the object, so if the object is a Level then enter the Level name (for example, Item). |
ENTITY_NAME | Name of the Demantra entity to be translated. For example, "My test worksheet". |
I18N_TEXT | Translated text. |
Note: Object Type Code, Attribute Type Code, Parent Object Name, and Entity Name columns are all case sensitive.
This procedure is run from the command line, and adds single translations to the Dictionary table. This procedure is run from the command line and is useful for storing translations for one or two entities in the Dictionary table without going through the standard import process.
Use the following syntax when running this procedure:
MLS_INTEG_IMPORT.TRANSLATION_API (locale_id, object_type_code, attribute_type_code, parent_object_name, entity_name, i18n_text)
For example:
SQL> exec MLS_INTEG_IMPORT.TRANSLATION_API('es_AR','1','QUERY_NAME','My Test Worksheet','Mi Prueba de Hoja de Cálculo');
Parameter | Description |
LOCALE_ID | Language indicator, which may be one of the following values:
|
OBJECT_TYPE_CODE | Object type, which may be one of the following values:
|
ATTRIBUTE_TYPE_CODE | Attribute of an object, for objects that have secondary details, and may be one of the following values:
|
PARENT_OBJECT_NAME | Parent of the object. For example, LEVEL is parent of members. This is the actual name of the object, so if the object is a Level then enter the Level name (for example, Item). |
ENTITY_NAME | Name of the Demantra entity to be translated. For example, "my test worksheet". |
I18N_TEXT | Translated text. |
If errors are encountered during loading, the associated records are moved to the I18N_DICTIONARY_STAGING_ERR table, with an error message providing details. The error table captures the exact error message and indicates which input is invalid. In this case, the record is not actually inserted into the dictionary table in that case, only the _ERR table.
For new content created during an implementation, translations can be maintained using a web-based translation utility. You can create new objects and content (worksheets, workflow, series) in any of the supported languages and then translate these objects to additional supported languages - particularly when objects are shared across users and regions. The Translation Utility is also translated, so users can select their preferred language when logging in.
Note: The translation utility is only used to add translations in other active languages. You cannot use the translation utility to change values in the default system language.
From within the Translation Utility, you can search for strings to translate using multiple criteria such as:
target translation language
whether Translations are missing, exist, or both
by Object Type, or by Parent Object Type
matching criteria on the attribute (for example, Worksheet Name LIKE Demand)
To use the Translation Utility:
Log in to the Demantra Local Application Administrator.
For example: http://my_server/demantra/portal/adminLogin.jsp
Select Translation Utility from the options menu.
The Translation Utility appears.
From the Target Translation Language drop-down list, choose the language in which the string you are searching for exists.
From the Translations drop-down list, choose one of:
Missing translations
Existing translations
All
In the Object Type field, choose from the list of available translatable Demantra objects.
In the Parent Object Type field, choose the type of parent object.
Note: The Parent Object Type field is only available when the selected Object Type has a parent object.
In the Attribute Type field, choose the attribute belonging to the object that you want to translate. The contents of this field depends on the selected object type.
Choose the appropriate search operator and text string on which to search.
Note: If the search field is left blank, Demantra returns a list of all relevant objects of this type.
Click Submit.
The Translation Utility returns all strings that match the selected values.
Update or fill in the translated text as required, and then click the Update button.
Any changes you make will be available immediately in Demantra worksheets (restarting the application server is not necessary).