This page deals with translation handling related to the IFS Analysis Models
The information in IFS Analysis Models is based on access of so called Access Views. These access views act as an extra access layer on top of existing fact and dimension views. For more information about access views, please refer to:
IFS Applications supports translation handling of metadata related to dimensions and Information Sources. This typically means that the display name of a dimension and its attributes can be translated to different languages using the standard translation principles. The translation support however only applies to IFS specific clients as e.g. IFS Business Reporter, IFS Lobby. Metadata translations will thus not be supported by the ETL process.
When it comes to other type of translations the following cases can be distinguished:
The extracting user, i.e. the <IFSINFO> user, has a preferred language that is the primary choice. Then there is also a default language if the preferred language property is empty.
For all cases where a translated text is retrieved as a result of a call to the IFS Applications translation framework, the following applies:
The language used, by framework methods, will be the preferred or the default language of the user, i.e. the <IFSINFO> user. This means that translatable data will be represented in the language according to the <IFSINFO> user preferences.
Now if the purpose is to view data related translations in a cube in e.g. French, after processing the ETL, then attributes and labels in the SSAS (SQL Server Analysis Services) cube might support French translations but the language depended data will still be in English.
It is possible to some extent handle translations in SSAS (please refer to standard SSAS documentation).
To get everything in a cube presented in the same language, first the cube itself will have to be translated and then it is possible modify the preferred/default language of the <IFSINFO> user and run the ETL process again to get data specific translations in the required language. Another options is to only use SSAS to translate everything, both data dependent translations and cubs specific names/labels etc.
Some data is dependent on the NLS settings of the Oracle session that transfers the data.
The typical case is time dimensions where e.g. the name of the day, the name of the month and the day of the week will be affected by the NLS settings. Important NLS settings are NLS_LANGUAGE, NLS_TERRITORY and NLS_DATE_LANGUAGE.
This means that e.g. if NLS_TERRITORY=SWEDEN, a Monday will be the 1st day of the week.
Setting NLS LANG to AMERICAN_AMERICA.AL32UTF8 e.g. means that a Monday will be the 2nd day of the week
SSAS provides the possibility to handle context specific translations of a cube, e.g. attribute names and labels, as well as data related translations.
Note: This translation handling has to be done manually since IFS does not supply any way of translating a cube
There is in a SSAS cubes a built in support to handle context specific translations, i.e. label texts, attribute names etc.
For the cube itself as for each dimension there is a tab where translations can be defined for each language to be supported. If a customer wants to get cube attribute texts translated to another language than the default, English, it is necessary to go through the contents of the cube and supply translations. As help it is of course possible to look into IFS clients to figure out the appropriate text. This applies of course only if the context to be translated exists as an attribute in a IFS client. There are many translation contexts in a cube that have no corresponding contexts in IFS Applications.
There is also in cubes a possibility to support data translations. The idea here is to assign language specific columns to supported languages. If e.g. a dimension has columns named Description, Description_fr, Description_sv, it is possible to assign the Description column to English, Description_fr to French and Description_sv to Swedish.
To handle this it is of course necessary to have the extra columns available where needed. The way out here would be to modify the core dimensions (or facts) to also fetch translated information into dedicated columns. But of course this is a rather big modification and the ETL process would have to be modified. As a last step the cubes would have to be modified and reprocessed.
Translations provide server support for client applications that can support multiple languages. Frequently, users from different countries view a cube and its dimensions. It is useful to be able to translate various elements of a cube and its dimensions into a different language so that these users can view and understand the cube. For example, a business user in France can access a cube from a workstation with a French locale setting, and see the object property values in French. However, a business user in Germany who accesses the same cube from a workstation with a German locale setting sees the same object property values in German.
The IFS Analysis Models also contains example reports and dashboards, non of them are language supported.
It should be possible to get correct translations from the source cube but there will, both in reports and dashboards, be specific texts as labels, titles etc. that are not part of the cube, rather report/dashboard specific.
Reports and dashboards must thus be handled individually/separately. The source cube must first support the required language and then the reports specific texts must also translated to the required language.