Results for “language_code”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

FND_NATURAL_LANGUAGES_TL is the translation table for FND_NATURAL_LANGUAGES within the Oracle E-Business Suite Application Object Library (FND). It is owned by the APPLSYS schema and stores the language-dependent, multilingual descriptive text associated with each natural language registered in the base table. Whereas the base FND_NATURAL_LANGUAGES table holds language-independent attributes, this "_TL" table carries the translatable columns — primarily NAME and DESCRIPTION — for each installed language in the EBS instance. The object is documented as VALID in ETRM for both release 12.1.1 and 12.2.2, and its physical schema is exposed with eleven columns.

From a dimensional modeling perspective, the heuristic Data Vault classification mined from the FK structure identifies this object as standalone. In Data Vault terms it is therefore best modeled as a satellite-like descriptive companion: the business key (LANGUAGE_CODE plus LANGUAGE) identifies a natural language record, and the surrounding descriptive and audit columns provide its translated attributes. Because no foreign-key parents were detected in the mined metadata, the table is treated as an independent descriptive reference rather than a hub or link.

Key Information Stored

The table is keyed by the composite primary key FND_NATURAL_LANGUAGES_TL_PK, defined on (LANGUAGE_CODE, LANGUAGE). The most important columns are:

• LANGUAGE_CODE — the Oracle language code (for example, "US" or "D"), part of the primary key.
• LANGUAGE — the language identifier, the second component of the primary key and the link back to the base table.
• NAME — the translated display name of the natural language.
• DESCRIPTION — the translated description text; also part of unique index U2.
• SOURCE_LANG — indicates the source language used when the row was created.
• CREATED_BY, CREATION_DATE — standard who/when audit columns for row insertion.
• LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN — standard audit columns for the most recent modification.
• ZD_EDITION_NAME — the editioning column supporting EBS Online Patching (Edition-Based Redefinition), present in the unique indexes U1 and U2.

Two unique indexes act as business-key candidates: U1 on (LANGUAGE_CODE, LANGUAGE, ZD_EDITION_NAME) and U2 on (DESCRIPTION, LANGUAGE, ZD_EDITION_NAME). The surrogate PK (LANGUAGE_CODE, LANGUAGE) identifies each translated row, while U1 and U2 enforce uniqueness of the natural language record and its translated description within an edition.

Common Use Cases and Queries

The table is typically queried to resolve the translated display name of a language for reporting, LOV population, and localization checks. A common pattern joins it to the base table and filters by the runtime session language:

• Retrieve translated names: SELECT LANGUAGE_CODE, NAME FROM FND_NATURAL_LANGUAGES_TL WHERE LANGUAGE = 'US' AND ZD_EDITION_NAME = 'SET1';
• Join to base: SELECT b.LANGUAGE_CODE, t.NAME FROM FND_NATURAL_LANGUAGES b, FND_NATURAL_LANGUAGES_TL t WHERE b.LANGUAGE_CODE = t.LANGUAGE_CODE AND b.LANGUAGE = t.LANGUAGE;
• Audit localized content completeness by comparing row counts per LANGUAGE against the base table.
• Localization and translation validation reports identifying missing NAME or DESCRIPTION values.

Because Online Patching editions are in play, queries should ordinarily constrain ZD_EDITION_NAME to the active edition to avoid returning superseded rows.

Related Objects

The principal related objects, based on the documented key structure, are:

• FND_NATURAL_LANGUAGES — the base table; join on LANGUAGE_CODE and LANGUAGE.
• FND_NATURAL_LANGUAGES_TL_PK — the primary-key constraint on (LANGUAGE_CODE, LANGUAGE).
• FND_NATURAL_LANGUAGES_TL_U1 and FND_NATURAL_LANGUAGES_TL_U2 — unique indexes enforcing business-key and description uniqueness per edition.
• FND_LANGUAGES — the language registry referenced indirectly via LANGUAGE_CODE.
• FND_TERRITORIES_TL — a parallel translated reference table following the same "_TL" pattern.

These associations reflect the documented metadata; consult the ETRM for the complete dependency list.