Chapitre 20. Localisation

Table des mati�res
20.1. Support de Locale
20.1.1. Vue d'ensemble
20.1.2. Avantages
20.1.3. Probl�mes
20.2. Support des jeux de caract�res
20.2.1. Jeux de Caract�res Support�s
20.2.2. Choisir le Jeu de Caract�res
20.2.3. Conversion de Jeu de Caract�res Automatique entre Serveur et Client
20.2.4. Plus de Lecture

Ce chapitre d�crit les fonctionnalit�s disponibles pour la localisation du point de vue de l'administrateur. PostgreSQL supporte la localisation en utilisant deux approches:

20.1. Support de Locale

Le support de Locale fait r�f�rence � une application respectant les pr�f�rences culturelles en ce qui concerne les alphabets, le tri, le formatage des nombres, etc. PostgreSQL utilise les possibilit�s du standard ISO C et de la locale POSIX fourni par le syst�me d'exploitation serveur. Pour plus d'information, consultez la documentation de votre serveur.

20.1.1. Vue d'ensemble

Le support de locale est automatiquement initialis� lorsque un cluster de base de donn�es est cr�� avec initdb. initdb va initialiser le cluster avec la valeur de locale de son environnement d'ex�cution; donc, si votre syst�me est d�j� param�tr� pour utiliser la locale que vous voulez dans votre cluster, vous n'avez rien d'autre � faire. Si vous voulez utiliser une locale diff�rente (ou si vous n'�tes pas sur de la locale qu'utilise votre syst�me), vous pouvez dire � initdb exactement quel locale vous voulez utiliser avec l'option --locale. Par exemple:

initdb --locale=sv_SE

Cette exemple met la locale � Su�dois (sv) tel que parl� en Su�de (SE). D'autres possibilit�s pourraient �tre en_US (l'anglais Am�ricain) et fr_CA (Canada, Fran�ais). Si plus d'un jeu de caract�res peuvent �tre utile pour une locale alors la sp�cification ressemble � ceci: cs_CZ.ISO8859-2. Quels locales sont disponibles sous quels noms d�pend de l'�diteur de votre syst�me d'exploitation et de ce qui est install�.

De fa�on occasionnelle, il est utile de m�langer les r�gles de plusieurs locales, i.e., utiliser les r�gles de tri anglais mais des messages en espagnol. Pour permettre ceci, des sous-cat�gories de locales existent qui ne contr�lent qu'un certain aspect des r�gles de localisation.

LC_COLLATEOrdre de tri des cha�nes de caract�res
LC_CTYPEClassification de caract�res(Qu'est ce qu'une lettre ? La majuscule �quivalente ?)
LC_MESSAGESLangage des messages
LC_MONETARYFormatage des montants de monnaie
LC_NUMERICFormatage des nombres
LC_TIMEFormatage des dates et heures

Les noms des cat�gories se traduisent en noms d'options initdb pour surcharger le choix de locale pour une cat�gorie donn�e. Par exemple, pour mettre la locale en fran�ais canadien tout en utilisant les r�gles am�ricaines pour le formatage de monnaie, utilisez initdb --locale=fr_CA --lc-monetary=en_US.

Si vous voulez que le syst�me se comporte comme s'il n'avait pas de support de locale, utilisez les locales sp�ciales C ou POSIX.

La nature de ces cat�gories de locales est que leur valeur doit �tre fix�es pour la dur�e de vie d'un cluster de base de donn�es. C'est a dire qu'une fois initdb lanc�e, on ne peut plus les changer. LC_COLLATE et LC_CTYPE sont ces cat�gories. Ils affectent l'ordre de tri des index, donc ils doivent rester fixes, ou les index sur les colonnes de texte deviendront corrompus. PostgreSQL applique ceci en enregistrant les valeurs de LC_COLLATE et LC_CTYPE qui sont vus par initdb. Le serveur adopte automatiquement ces deux valeurs lorsqu'il est lanc�.

Les autres cat�gories de locale peuvent �tre chang�s comme d�sir� lorsque le serveur est lanc� en fixant les variables d'environnement qui ont le m�me nom que les cat�gories de locale (voir Section 16.4 pour plus de d�tails). Les valeurs par d�faut choisies par initdb sont en fait seulement �crits dans le fichier de configuration postgresql.conf pour servir de valeur par d�faut quand le serveur est lanc�. Si vous effacez ces d�clarations de postgresql.conf, alors le serveur h�ritera des param�tres de l'environnement d'ex�cution.

Notez que le comportement de locale du serveur est d�termin� par les variables d'environnement vues par le serveur, pas l'environnement d'un client quelconque. Alors, faites attention de configurer les bons param�tres de locale avant de lancer le serveur. Une cons�quence de ceci est que, si le client et le serveur ont des locales diff�rents, les messages appara�tront dans des langues diff�rents suivant d'o� ils viennent.

Note�: Lorsqu'on parle d'h�riter la locale de l'environnement d'ex�cution, ceci veut dire la chose suivante sur la plupart des syst�mes d'exploitation: Pour une cat�gorie de locale donn�e, disons l'ordonnancement, les variables d'environnement suivantes sont consult�es dans cet ordre jusqu'� ce qu'on en trouve une de fix�e: LC_ALL, LC_COLLATE (la variable correspondante � la cat�gorie respective), LANG. Si aucune de ces variables n'est fix�e, alors on utilise la locale par d�faut de C.

Certaines biblioth�ques de localisation regardent aussi la variable d'environnement LANGUAGE qui surcharge tout autre param�tre pour le besoin de fixer la langue des messages. Si vous doutez, lisez la documentation de votre syst�me d'exploitation, en particulier la documentation � propos de gettext, pour plus d'information.

Pour permettre la traduction des messages dans la langue pr�f�r�e de l'utilisateur, NLS doit �tre activ� pendant la compilation. Ce choix est ind�pendant d'autre support de locale.

20.1.2. Avantages

Le support de locale influence en particulier les fonctionnalit�s suivantes:

  • Ordre de tri dans les requ�tes utilisant ORDER BY

  • La famille de fonctions to_char

Le seul inconv�nient s�v�re d'utiliser le support de locale dans PostgreSQL est sa vitesse. Alors utilisez les locales seulement si vous en avez besoin.

20.1.3. Probl�mes

Si le support de locale ne fonctionne pas malgr� l'explication ci-dessus, v�rifiez que le support de locale de votre syst�me d'exploitation est correctement configur�. Pour v�rifier quelles locales sont install�es sur votre syst�me, vous pouvez utiliser la commande locale -a si votre syst�me d'exploitation le fournit.

V�rifiez que PostgreSQL utilise vraiment la locale que vous supposez. Les param�tres LC_COLLATE et LC_CTYPE sont d�termin�s lors de initdb et ne peuvent pas �tre modifi�s sans r�p�ter initdb. D'autres param�tres de locale, y compris LC_MESSAGES et LC_MONETARY sont d�termin�s initialement par l'environnement dans lequel le serveur est lanc�. Vous pouvez v�rifier les param�tres LC_COLLATE et LC_CTYPE d'une base de donn�es avec l'utilitaire pg_controldata.

Le r�pertoire src/test/locale dans la distribution du source contient une s�rie de tests pour le support de locale dans PostgreSQL.

Les applications clientes qui g�rent les erreurs c�t� serveur en analysant le texte du message d'erreur auront, bien sur, des probl�mes lorsque les messages sont dans une langue diff�rente. Les auteurs de telles applications sont invit�s � utiliser le sch�ma de code d'erreur � la place.

Maintenir des catalogues de traductions de messages requiert les efforts permanents de beaucoup de volontaires qui souhaitent voir PostgreSQL bien interpr�ter leur langue pr�f�r�e. Si des messages dans votre langue ne sont pas disponibles ou compl�tement traduits, votre aide serait tr�s appr�ci�e. Si vous voulez aider, consultez le Chapitre 46 ou �crivez � la liste de diffusion des d�veloppeurs.