Related Language Records

PeopleSoft supports your application to be used in a defined set of multiple languages. It means if you login with French you will see all the data including navigation, help texts, page and component names and transaction data in French. For the same transaction if you login with English you will see the data in English as well. PeopleSoft will internally take care of all the translation of languages. But if you have customized your application, this is how you can use the multi-lingual feature for transaction data – using related language records.

Related Language Records

If you want to store your transaction data in multiple languages, you need some place to store the data. That place is related language records.  All your data in base language (language for which your app is installed- SELECT LANGUAGE_CD FROM PSOPTIONS) will be stored in the actual transaction table where as the data entered in other language is stored in the related language record. Each language will be identified by additional key, LANGUAGE_CD, in your related language record.

When you create related language records, you should consider the following.

1.       The keys of the related language record should contain all the keys of the base record in the same order.

2.       You should add an extra key, LANGUAGE_CD, as the last key for the record (exception is only for EFFDT field).

3.       Apart from the keys, your language record needs only the fields which need to be translated. Ie. DECR etc..

For example I have a record ABC with two fields EMPLID(Key Field) and ADDRESS. Now if I want to create an language record (ABC_LNG), to translate the address, then the record should contain three fields EMPLID(Key), LANGUAGE_CD(Key) and ADDRESS.

Now for translation to happen you need to assign the related language record to the base record. To do this, open the properties of the base record. Then go to the “Use” tab and provide the name of “Related Language Record” as the one which you created now.

Now I will tell you how this translation is going to work. For that I am taking the record example mention earlier.

Base Record: ABC

EMPLID	ADDRESS
001	Hudson Street, Near Almond junction
002	ABCD, EFG

Related language record: ABC_LNG

EMPLID	LANGUAGE_CD	ADDRESS
001	FRA	Hudson Street, environs de Almond jonction
001	DUT	Hudson Street, zona de Almond unión

Let us assume the base language is in English. Now I have actually 2 entries in the table ABC. If you observe the related language record, you can see that there are two entries for employee id 001 and zero entry for employee id 002.

Consider employee 001.

When you open in English, the address will be displayed as “Hudson Street, Near Almond junction”.

If you login with French, the address will be displayed as “Hudson Street, environs de Almond jonction ».

Now if you login with Dutch then the address will be « Hudson Street, zona de Almond unión”.

Consider employee 002.

Since this employee does not contain any data in any of the language records, if you login with any language the description will be same “ABCD, EFG”.

The logic is, when you login to the system, it will check if the base language and logged in language is same. If it is same then the data is displayed from the base record. If it is different;  then system will check the related language record to see if it has the data for logged in language. If data is found in the related language record, then it is displayed from the related language record otherwise from the base record.

Related Language Views

 It is an extension to the related language table concept. All the rules remain same for views also. This will come in picture when you are creating views for the transaction tables which have translation data enabled.

The only thing you need to take care is to join the related table in the related language view. Take the previous examples.

I will create a view (simple view for demonstration) with below specifications.

View: ABC_VW

Fields: EMPLID (Key), NAME, ADDRESS

SQL:  SELECT A.EMPLID, P.NAME, A.ADDRESS FROM  PS_ABC A, PS_PERSONAL_DATA P WHERE A.EMPLID = P.EMPLID

Now the structure of my related language view should be as below.

View: ABC_LNG_VW

Fields: EMPLID(Key), LANGUAGE_CD(Key), NAME, ADDRESS

SQL: SELECT A.EMPLID, L.LANGUAGE_CD, P.NAME, A.ADDRESS FROM PS_ABC A, PS_PERSONAL_DATA P, PS_ABC_LNG_VW L WHERE A.EMPLID = P.EMPLID AND A.EMPLID = L.EMPLID

Now you need to add the record ABC_LNG_VW to the record ABC_VW. The address field will get translated in the same way as your base table ABC does. If you want to translate the name field also, then you need to add the related language record for PERSONAL_DATA in the language view sql.