Documentation PostgreSQL 14.22 » Administration du serveur » Localisation » Support des locales

Précédent | Niveau supérieur | Suivant
Chapitre 24. Localisation | Sommaire | 24.2. Support des collations

## 24.1. Support des locales

Le support des locales fait référence à une application respectant les préférences culturelles portant sur les alphabets, le tri, le format des nombres, etc. PostgreSQL utilise les outils C et POSIX du standard ISO fournis par le système d'exploitation du serveur. Pour plus d'informations, consulter la documentation du système.

### 24.1.1. Aperçu

Le support des locales est configuré automatiquement lorsqu'une instance de base de données est créée avec `initdb`. `initdb` initialise l'instance avec la valeur de locale de son environnement d'exécution par défaut. Si le système est déjà paramétré pour utiliser la locale souhaitée pour le cluster, il n'y a donc rien d'autre à faire. Si l'on désire une locale différente, ou si celle du serveur n'est pas connue avec certitude, il est possible d'indiquer à `initdb` la locale à l'aide de l'option `--locale`. Par exemple :

    initdb --locale=sv_SE

Cet exemple pour les systèmes Unix positionne la locale au suédois (`sv`), tel que parlé en Suède (`SE`). Parmi les autres possibilités, on peut inclure `en_US` (l'anglais américain) ou `fr_CA` (français canadien). Si plusieurs ensembles de caractères peuvent être utilisés pour une locale, alors les spécifications peuvent prendre la forme `langage_territoire.codeset`. Par exemple, `fr_BE.UTF-8` représente la langue française, telle qu'elle est parlée en Belgique (BE), avec un encodage UTF-8.

Les locales disponibles et leurs noms dépendent de l'éditeur du système d'exploitation et de ce qui est installé. Sur la plupart des systèmes Unix, la commande `locale -a` fournit la liste des locales disponibles. Windows utilise des noms de locale plus verbeux, comme `German_Germany` ou `Swedish_Sweden.1252`, mais le principe est le même.

Il est parfois utile de mélanger les règles de plusieurs locales, par exemple d'utiliser les règles de tri anglais avec des messages en espagnol. Pour cela, des sous-catégories de locales existent qui ne contrôlent que certains aspects 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 ? Et la majuscule équivalente ?)
`LC_MESSAGES` | Langue des messages
`LC_MONETARY` | Formatage des valeurs monétaires
`LC_NUMERIC` | Formatage des nombres
`LC_TIME` | Formatage des dates et heures

Les noms des catégories se traduisent en ceux des options d'`initdb` pour surcharger le choix de locale d'une catégorie donnée. Par exemple, pour utiliser la locale français canadien, mais avec des règles américaines de formatage monétaire, utilisez `initdb --locale=fr_CA --lc-monetary=en_US`.

Si vous voulez un système qui se comporte comme s'il n'avait aucun support des locales, utilisez les locales spéciales `C`, ou l'équivalent `POSIX`.

Certaines catégories de locales doivent être fixées à la création de la base de données. Elles peuvent différer entre bases de données, mais, une fois la base créée, elles ne peuvent plus être modifiées. `LC_COLLATE` et `LC_CTYPE` sont ces catégories. Elles affectent l'ordre de tri des index, et doivent donc rester inchangées, les index sur les colonnes de texte risquant d'être corrompus dans le cas contraire. (Mais vous pouvez lever ces restrictions grâce aux collations, comme discuté dans Section 24.2.) Les valeurs par défaut de ces catégories sont déterminées à l'exécution d'`initdb`, et utilisées à la création de nouvelles bases de données, sauf indication contraire dans la commande `CREATE DATABASE`.

Les autres catégories de locale peuvent être modifiées à n'importe quel moment en configurant les variables d'environnement de même nom (voir Section 20.11.3 pour de plus amples détails). Les valeurs choisies par `initdb` sont en fait juste écrites dans le fichier de configuration `postgresql.conf` pour servir de valeurs par défaut au démarrage du serveur. Si elles sont supprimées du fichier `postgresql.conf`, le serveur hérite des paramètres de son environnement d'exécution.

Notez que les locales du serveur sont déterminées par les variables d'environnement vues par le serveur, pas par celles de l'environnement d'un quelconque client. Il est donc important de configurer les bons paramètres de locales avant le démarrage du serveur. En conséquence, si les locales du client et du serveur diffèrent, les messages peuvent apparaître dans des langues différentes en fonction de leur provenance.

### Note

Hériter la locale de l'environnement d'exécution signifie, sur la plupart des systèmes d'exploitation, la chose suivante : pour une catégorie de locales donnée (disons la collation) les variables d'environnement suivantes sont consultées dans cet ordre jusqu'à en trouver une qui est définie : `LC_ALL`, `LC_COLLATE` (ou la variable correspondant à la catégorie) et `LANG`. Si aucune de ces variables n'est définie, la locale devient par défaut `C`.

Certaines bibliothèques de localisation regardent aussi la variable d'environnement `LANGUAGE`, laquelle surcharge tout autre paramètre pour fixer la langue des messages. En cas de doute, lire la documentation du système d'exploitation, en particulier la partie concernant gettext.

Pour permettre la traduction des messages dans la langue préférée de l'utilisateur, NLS doit avoir été activé à la compilation (`configure --enable-nls`). Le reste de l'outillage des locales est automatiquement inclus.

### 24.1.2. Comportement

Le paramétrage de la locale influence les fonctionnalités SQL suivantes :

- l'ordre de tri dans les requêtes utilisant `ORDER BY` ou les opérateurs de comparaison standards sur des données de type texte ;

- les fonctions `upper`, `lower` et `initcap` ;

- les opérateurs de correspondance de motifs (`LIKE`, `SIMILAR TO` et les expressions rationnelles de type POSIX) les locales affectent les opérateurs insensibles à la classe, et le classement des caractères par les expressions rationnelles portant sur des caractères ;

- la famille des fonctions `to_char`. ;

- l'utilisation d'index avec des clauses `LIKE`.

L'inconvénient du support dans PostgreSQL des locales (autres que `C` ou `POSIX`) est l'impact sur les performances. Il ralentit la gestion des caractères, et empêche l'utilisation des index ordinaires lors d'un `LIKE`. Pour cette raison, il est préférable de n'utiliser les locales qu'en cas de réel besoin.

Toutefois, il existe plusieurs classes d'opérateurs personnalisées pour permettre à PostgreSQL d'utiliser des index avec les clauses `LIKE` et une locale autre que `C`. Ces classes permettent la création d'un index réalisant une stricte comparaison caractère par caractère, en ignorant les règles de comparaison des locales ; se référer à la Section 11.10 pour plus d'informations. Une autre possibilité est de créer des index en utilisant la collation `C`, comme discuté dans Section 24.2.

### 24.1.3. Problèmes

Si le support des locales ne fonctionne pas au regard des explications ci-dessus, vérifiez que le support au niveau du système d'exploitation est correctement configuré. Pour vérifier les locales installées sur le système, on peut utiliser la commande `locale -a`, si elle est fournie avec le système d'exploitation.

Il faut vérifier que PostgreSQL utilise effectivement la locale que vous pensez. Les paramètres `LC_COLLATE` et `LC_CTYPE` sont déterminés lors de la création de la base de données, et ne peuvent pas être modifiés, sauf en créant une nouvelle base de données. 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 peuvent être modifiés pendant l'exécution. Pour vérifier la locale active, utilisez la commande `SHOW`.

Le répertoire `src/test/locale` de la distribution source contient une série de tests pour le support des locales dans PostgreSQL.

Certaines applications clientes, qui gèrent les erreurs en provenance du serveur en analysant le texte des messages associés, auront évidemment des problèmes lorsque ces messages du serveur seront dans une autre langue. Les auteurs de telles applications sont invités à utiliser plutôt le mécanisme de code d'erreur.

Le maintien de catalogues de traduction des messages nécessite les efforts permanents de beaucoup de volontaires souhaitant voir PostgreSQL parler correctement leur langue préférée. Si certains messages dans une langue ne sont pas disponibles, ou pas complètement traduits, toute aide est la bienvenue. Pour apporter votre aide à ce projet, consultez le Chapitre 55, ou écrivez à la liste de diffusion des développeurs.