Re: Multi-language support

Hi Denis, Denis GILARDIN wrote: > > Hi, > > I want to build an international database which support 40 european or pan > european languages. My informix environment is INFORMIX 7.22. Is GLS my > solution ? > yes and no. 1. If you will use char and varchar in your database you can leave your GLS environment unchanged. 2. If you want to have local sorted rows you have to use nchar and nvarchar But here is your problem: You have to design your GLS environment as ln_tr.codset@modifier ln means language (eg. english[en], german[de], french[fr], italien[it]) tr means territory (eg. swiss[ch], united states[us], great britain[gb]) code set (1252 equal to ISO8859-1 for western europe, 1250 for eastern europe) modifier different types of local standards So you can define 3 language types for swiss: de_ch.1252, it_ch.1252, fr_ch.1252 You could have one type for germany: de_de.1252 You could have 2 types for english: en_us.1252, en_gb.1252 You could have a different code set for (eg.) poland: pl_pl.1250 A database can hold only one language type: en_gb.1252 (for example) All character indexes are generated in this language. If a client with another language connects, an order by uses virtual memory and tempspaces to sort your rows (even, you have an defined index). If a client with another code set connects, the database has to translate the foreign code set into its own code set. But it can do this only if the characters from the foreign code set are defined in its local code set, too. The same procedure is used for sending data to the client. Example: Our database (en_gb.1252) gets an character from a german client (a&umlaut). This character is defined in the used code set (1252). The database can store it, without transformation. Now, a poland client request the row with the german character. But the german character is not defined in the poland code set (1250). So the data can not be transformed. You have the following possibilities: 1. You can use UNICODE, but you need a IUS 9.14 or higher for this 2. You can use UTF-8, but working with this code set is a little bit tricky and do not improve your performance 3. You can use the default (en_us.8859-1 on Unix, en_us.1252 on NT). All clients have to use the default code set. Now, you are able to send all characters to the database. But you can not use local sortings. Please refere to "Guide to GLS Functionality", Chapter 7, Managing GLS-Files for further information. Yours, Volker