PeopleSoft supports your application to be used in a defined set of multiple languages. It means if you log in with Arabic, you will see all the data including navigation, help texts, page and component names and transaction data in Arabic. For the same transaction, if you log in 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 whereas the data entered in other language is stored in the related language record. Each language will be identified by an 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 ADDRESSES with two fields EMPLID(Key Field) and ADDRESS. Now, if I want to create a language record (ADDRESS _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: ADDRESSES

    Related language record: ADDRESSES _LNG

  Let us assume the base language is in English. Now I have actually 2 entries in the table ADDRESSES. If you observe the related language record, you can see that there is an entry 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 Metro junction”. If you log in with Arabic, the address will be displayed as “شارع هدسون ، بالقرب من تقاطع ».   Consider employee 002. Since this employee does not contain any data in any of the language records, if you log in with any language the description will be the same “ABCD, EFG”.   The logic is, when you log in to the system, it will check if the base language and logged in language is the same. If it is the same, then the data is displayed from the base record. If it is different, then the 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 the 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: ADDRESSES_VW   Fields: EMPLID (Key), NAME, ADDRESS SQL:  SELECT A.EMPLID, P.NAME, A.ADDRESS FROM PS_ADDRESSES A, PS_PERSONAL_DATA P WHERE A.EMPLID = P.EMPLID   Now the structure of my related language view should be as below.   View: ADDRESSES_LNG_VW   Fields: EMPLID(Key), LANGUAGE_CD(Key), NAME, ADDRESS SQL: SELECT A.EMPLID, L.LANGUAGE_CD, P.NAME, A.ADDRESS FROM PS_ADDRES A, PS_PERSONAL_DATA P, PS_ADDRESSES_LNG_VW L WHERE A.EMPLID = P.EMPLID AND A.EMPLID = L.EMPLID   Now you need to add the record PS_ADDRESSES_LNG_VW to the record ADDRESSES_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.