| Documentation PostgreSQL 8.0.25 | ||||
|---|---|---|---|---|
| Précédent | Arrière rapide | Avance rapide | Suivant | |
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:
Utiliser les fonctionnalités de locale du système d'exploitation pour donner un ordonnancement de tri, formatage de chiffre, des messages traduits et et autres aspects spécifiques à la locale.
Donner un certain nombre de jeu de caractères différents définis dans le serveur PostgreSQL, y compris des jeux de caractères multi-bit, pour permettre de stocker du texte dans toutes sortes de langues, et offrir la traduction de jeu de caractère entre serveur et client.
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.
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 par défaut. 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 utiliser en spécifiant 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 (français canadien). 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é. (Sur la plupart des systèmes, la commande locale -a fournira une liste de locales disponibles.)
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_COLLATE | Ordre de tri des chaînes de caractères |
| LC_CTYPE | Classification de caractères(Qu'est ce qu'une lettre ? La majuscule équivalente ?) |
| LC_MESSAGES | Langage des messages |
| LC_MONETARY | Formatage des montants de monnaie |
| LC_NUMERIC | Formatage des nombres |
| LC_TIME | Formatage des dates et heures |
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.8.2 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.
Le support de locale influence les fonctionnalités suivantes :
La famille de fonctions to_char
L'inconvénient d'utiliser le support de locale autres que C ou POSIX dans PostgreSQL est son impact sur les performances. Il ralentit la gestion des caractères et empêche l'utilisation des index ordinaires par LIKE. Pour cette raison, utilisez les locales seulement si vous en avez besoin.
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é mais peut être modifié en cours. Vous pouvez vérifier les paramétrages de la locale active en utilisant la commande SHOW.
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 pas complètement traduits, votre aide serait très appréciée. Si vous voulez aider, consultez le Chapitre 44 ou écrivez à la liste de diffusion des développeurs.
| Précédent | Sommaire | Suivant |
| Problèmes d'authentification | Niveau supérieur | Support des jeux de caractères |