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.