Investigating EBS NLS Translation and NLS Data Load problems

EBS translation is done by applying NLS translation patches using adpatch.
This process actually uploads the NLS Data to the database via FNDLOAD utility.
FNDLOAD uploads the data in the .ldt files to the translation tables (_TL)
FNDLOAD uses the controlfiles (.lct) to gather the information for  the data structure.
Using NLS dAta in ldt files are uploaded to the TL tables, actually this process updates the rows that belongs to translated Language.


For example;

ICX_CAT_ATTRIBUTES_TL table contains  a record in TR for every attributes.

1 TR TR Küçük Resim Kalemin küçük resim görüntüsü (GIF veya JPEG formatı)
1 US US Thumbnail Image Thumbnail image of the item (GIF or JPEG format)


This TR records are generated by adadmin's Maintain Multi-lingual tables option.
This options creates the records for each of the languages that does not have records in the _TL tables.
So FNDLOAD actually updates this records..
Maintain Multi-lingual tables option creates records based on the licenced languages in the Oracle Applications.
so that's why, before running Multi-lingual tables, the language should be licensed using OAM.

So for NLS translation following actions should be taken in sequence.

1) License the new language
2) Maintain Multi-Lingual tables
3) Apply Nls translation patch.


Nls translation in EBS becomes a problematic process in some cases.

For example, data is in the ldt , nls translation patch is applied, but the relevant text is still appearing in English .
Or, translation is done, but translated text is invalid.

In the kind of situation an investigation is required and following method should be followed to investigate and fix the translation problem.

First of all, NLS patching steps that I mentioned above should be checked. If all the steps are done, applied and no problems encountered;
then Ldt files are a good place to start investigation.

Ldt files are the cores for files in this nls translation process, as they are where the nls data resides actually.
First of all, the ldt file/files that belongs to the problematic interface/form should be found.
To find problematic ldt files, finding the module name of the form/menu etc.. will be very helpful . Module/product name can be found using System Administrator-> Application -> Menu(for example)
After finding the module/product name , cd to $PRODUCT_TOP/patch/115/import/US (also search the $PRODUCT_TOP/admin/import directory recursively) and find the ldt file using OS tools. (like ls , grep ,cat)
When the US ldt file is found (it is actually ldt file of US language), ldt file of corresponding Language can be found easily by changing the current working directory to $PRODUCT_TOP/patch/115/import/(LANGUAGE) and using the language independent data in US ldt file.
For example, if it s a menu; find the menu name in US ldt and locate the TR ldt file by using grep -i 'FND_NAVSITE4.0' * command in New Language directory. -- ldt files are generally have the same name for US and other languages..

After finding the actual ldt, its contents can be checked with Os tools ( like vi)
If the translation is not correct, file can be edited to reflect the tranlation and loaded with FNDLOAD again.
For example;

FNDLOAD APPS/APPS 0 Y UPLOAD \
   @FND:patch/115/import/afsload.lct \
   @FND:patch/115/import/ESA/afnlnlg.ldt - UPLOAD_MODE=NLS WARNINGS=TRUE


If the translation is already correct, uploading the data can solve the translation problem.. Because, there could be a problem in NLS patching process for that ldt file.

After uploading the data ; application services should be restarted..