Fusion Concepts: Multi-Lingual Support

Fusion Applications support internationalization extensively. This is not limited to just the shipped applications. Customization developers can take advantage of the framework support to build or customize existing components with multi-lingual support. Here are the terms and concepts on how this is done in Fusion Applications

Multi-lingual Entities: Multi-lingual entities are those that maintain one or more translated attributes, and for which it is a requirement to store all relevant translations of these attributes.

Base Language: is the primary operating language for an installation.

Base Attribute: is the one which that is not translated and do not very by language e.g. APPLICATION_SHORT_NAME.

Translated Attribute: is the one which is maintained for all the translated languages. Multi-lingual entities are implemented using two database tables.

The base table holds the base attributes and the translation table holds the translated attributes.The detail table has as many rows as the installed languages per base table row. Translation table's primary key is made up of the primary key of the base table and the language_code column in FND_LANGUAGES table. 

There are cases where most of the attributes are translated so in those cases only translation table is created and base attributes are just replicated e.g EGP_ITEM_STATUS_TL and EGPITEM_TEXT_TL. As applications run in a single language for any given user session at any given point of time so a multi-lingual view is created combining the base table and the translation table there by filtering translations to runtime language. This view uses the userenv('LANG') expression to select the correct translation based on the session language (which usually comes from the NLS_LANG environment variable)

Naming Standards

  • Base Table: PROD_ENTITY_B
  • Translation Table: PROD_ENTITY_TL
  • Language Column: Language
  • Source Language: SOURCE_LANG
  • Multi-lingual View: PROD_ENTITY_VL

Example: A base table and a standard table may looks like below:

CN_RS_RULES_ALL_B

RULE_ID                  ENABLED_FLAG     USAGE_ID
---------------------- ------------ ----------------------
100000018558481        Y                        -1001
300100003303029        Y                        -1002
300100018916455        Y                        -1001

And translation table like below:

CN_RS_RULES_ALL_TL

RULE_ID                 LANGUAGE SOURCE_LANG NAME
---------------------- -------- ----------- ---------------------------------------------------------------
100000018558481 US                US                       2011 NA Green Server Line - Manufacturing

300100018916455 US                US                       TEST CREDIT RULE_20130109095022

300100003303029 US                US                       Commission-printer node

300100003303029 KO               KO                       [Commission-printer nodeΩ'+++ '+++ '+Ø

100000018558481 KO               KO                       [2011 NA Green Server LineΩ'+++ '+++ '+

300100018916455 KO               US                       CREDIT RULE_20130109095022

Comments:

Can you explain how the langguage and Source_lang columns work in the example of the CN_RS_RULES_ALL_TL table you showed?

Posted by Jay on February 05, 2014 at 08:57 PM PST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Follow us on twitter Fusion Applications Extensibility, Customizations and Integration forum Fusion Applications Dev Relations YouTube Channel
This blog offers news, tips and information for developers building extensions, customizations and integrations for Oracle Fusion Applications.

Search

Categories
Archives
« May 2015
SunMonTueWedThuFriSat
     
1
2
4
6
8
9
10
11
13
14
16
17
18
20
22
23
24
25
26
27
28
29
30
31
      
Today