Re: Internationalization... Multi language environments

If there's a Redbook, there is also a regular globalization manual - look it up in Knowledge Center using the word "globalization".

There are at least 2 different areas to work in - translation and conversion - the latter is often handled best by externalizing literals, putting them into message descriptions or files that are tagged with the CCSID. Then the same program under a different language will find the right CCSID to use and convert to it.

HTH
Vern

On 1/26/2017 9:13 AM, Rob Berendt wrote:

I think there might be a redbook or some such thing on this.


Rob Berendt
-- IBM Certified System Administrator - IBM i 6.1 Group Dekko Dept 1600 Mail to: 2505 Dekko Drive Garrett, IN 46738 Ship to: Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com From: Mohammad Tanveer <surgum@xxxxxxxxx> To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx> Date: 01/26/2017 10:10 AM Subject: Internationalization... Multi language environments Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx> Are there any best practices for Internationalization (multi language environments) to make life easier? For example if your application is used across the Globe and code base is same isn't it better to keep data in Unicode CCSID 1208 or 1200 in Database/Fields and IFS files. instead of keeping database in different CCSID for each country language? 1208 DB2 uses CCSID 1208 for Unicode UTF-8 data, which DB2 always considers to be mixed data. This CCSID is the default CCSID value for Unicode tables. Therefore, DB2 uses CCSID 1208 for CHAR, VARCHAR, and CLOB columns that are defined with FOR MIXED DATA in Unicode tables. FOR MIXED DATA is the default subtype specification. 1200DB2 uses CCSID 1200 for Unicode UTF-16 data, which is double-byte data (DBCS). This CCSID applies to GRAPHIC and VARGRAPHIC Unicode data. Therefore, DB2 uses CCSID 1200 for GRAPHIC, VARGRAPHIC, and DBCLOB columns in Unicode tables.