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.
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.
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.
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 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 ;
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.
Les locales peuvent être sélectionnées dans différentes configurations
suivant les besoins. L'aperçu ci-dessus montrait comment les locales sont
spécifiées en utilisant initdb pour configurer les
valeurs par défaut pour l'instance complète. La liste suivante montre où les
locales peuvent être sélectionnées. Chaque élément fournit les valeurs par
défaut pour les éléments suivants, et chaque élément inférieur permet de
surcharger les valeurs par défaut sur une granularité plus fine.
Comme expliqué ci-dessus, l'environnement du système d'exploitation fournit les valeurs par défaut pour les locales d'une instance tout juste initialisée. Dans de nombreux cas, c'est suffisant : si le système d'exploitation est configuré pour le langage/territoire désiré, alors PostgreSQL se comportera par défaut suivant cette locale.
Comme affiché ci-dessus, les options en ligne de commande
d'initdb indiquent les paramétrages de la locale pour
une instance tout juste initialisée. Utilisez-les si le système
d'exploitation n'a pas la configuration de locale que vous souhaitez pour
votre système de bases de données.
Une locale peut être sélectionnée séparément pour chaque base de données.
La commande SQL CREATE DATABASE et son équivalent en
ligne de commande, createdb, ont des options pour cela.
Utilisez-la par exemple si une instance contient des bases avec plusieurs
propriétaires ayant des besoins différents.
Les configurations de locale peuvent être faites pour les colonnes individuelles des tables. Il faut passer par un objet SQL appelé une collation, qui est expliqué dans Section 24.2. Utilisez-la par exemple pour trier des données dans différentes langues ou pour personnaliser l'ordre de tri d'une table particulière.
Enfin, les locales peuvent être sélectionnées pour une requête individuelle. De nouveau, cela utilise des objets SQL de collation. Cela permet de modifier l'ordre de tri en se basant sur un choix au moment de l'exécution ou pour une expérimentation.
PostgreSQL accepte plusieurs
fournisseurs de locale. Elle indique la bibliothèque
qui fournit les données de locale. Un nom de fournisseur standard est
libc, qui utilise les locales fournies par la
bibliothèque C du système d'exploitation. Ce sont les locales utilisées par
la plupart des outils fournis par le système d'exploitation. Un autre
fournisseur est icu, qui utilise la bibliothèque externe
ICU. Les locales ICU peuvent
seulement être utilisées si le support d'ICU a été configuré lors de la
construction de PostgreSQL.
Les commandes et outils qui sélectionnent les paramètres de la locale, comme
décrit ci-dessus, ont tous une option pour sélectionner le fournisseur de la
locale. Les exemples montrés ci-dessus utilisent le fournisseur
libc, qui est le fournisseur par défaut. Voici un exemple
pour initialiser une instance de bases en utilisant le fournisseur
ICU :
initdb --locale-provider=icu --icu-locale=en
Voir la description des commandes et programmes respectifs pour les détails.
Notez que vous pouvez mélanger les fournisseurs de locale sur différentes
granularités, par exemple utiliser libc par défaut pour
l'instance, mais avoir une base qui utilise le fournisseur
icu, puis avoir les objets de collation utilisant un des
fournisseurs dans ces bases.
Le fournisseur de locale à utiliser dépend des besoins individuels. Pour des utilisations basiques, chaque fournisseur donnera des résultats adéquats. Pour le fournisseur libc, il dépend de ce qu'offre le système d'exploitation ; certains systèmes d'exploitation sont meilleurs que d'autres. Pour des utilisations avancées, ICU offre plus de variants de locale et plus d'options de personnalisation.
Le format ICU pour les noms de locale est une étiquette de langage.
CREATE COLLATION mycollation1 (provider = icu, locale = 'ja-JP'); CREATE COLLATION mycollation2 (provider = icu, locale = 'fr');
Quand un nouvel objet collation ICU ou base de données avec un fournisseur ICU est défini, le nom donné de la locale est transformé (« canonisé ») en une étiquette de langage s'il n'est pas déjà sous cette forme. Par exemple,
CREATE COLLATION mycollation3 (provider = icu, locale = 'en-US-u-kn-true'); NOTICE: using standard form "en-US-u-kn" for locale "en-US-u-kn-true" CREATE COLLATION mycollation4 (provider = icu, locale = 'de_DE.utf8'); NOTICE: using standard form "de-DE" for locale "de_DE.utf8"
Si vous voyez cette notification, assurez vous que le fournisseur
et la locale sont bien le résultat attendu. Pour des résultats
cohérents lors de l'utilisation du fournisseur ICU, spécifiez l'étiquette de langage
canonique au lieu de s'appuyer sur la transformation.
Une locale sans nom de langage, ou le nom de langage spécial
root, est transformée pour avoir le langage
und ("indéfini").
ICU peut transformer la plupart des noms de locales libc, ainsi que d'autre formats, en étiquette de langage pour faciliter la transition vers ICU. Si un nom de locale libc est utilisé en ICU, il peut ne pas avoir exactement le même comportement qu'en libc.
S'il y a un problème d'interprétation de nom de locale, ou si le nom de locale représente un langage ou une région non reconnus par ICU, vous verrez l'avertissement suivant :
CREATE COLLATION nonsense (provider = icu, locale = 'nonsense'); WARNING: ICU locale "nonsense" has unknown language "nonsense" HINT: To disable ICU locale validation, set parameter icu_validation_level to DISABLED. CREATE COLLATION
icu_validation_level contrôle comment le message est
affiché. À moins qu'il soit affiché à ERROR, la collation
sera toujours créée,
mais le comportement pourrait ne pas être ce qui est attendu par l'utilisateur.
Une étiquette de langage, définie en BCP 47, est un identifiant standardisé utilisé pour identifier les langages, régions et autres informations à propos d'une locale.
Les étiquettes de langage basiques sont simplement
langage-région ;
ou même juste langage. Le
langage est un code de langage
(i.e. fr pour le français), et
région est un code de région
(i.e. CA pour le Canada). Par exemple :
ja-JP, de ou
fr-CA.
Les paramètres de collation peuvent être inclus dans l'étiquette de langage pour personnaliser le comportement de la collation. ICU permet une personnalisation étendue, telle que la sensibilité (ou insensibilité) aux accents, casse, et ponctuation ; traitement des chiffres à l'intérieur du texte ; et bien d'autres options pour satisfaire une variété de cas d'usage.
Pour inclure ces informations de collation supplémentaires dans une étiquette
de langage, ajouter -u,
qui indique qu'il y a des paramètres supplémentaires de collation, suivi par une ou
plusieurs paires
-clé-valeur
La clé est la clé pour le paramètre de collation et
valeur est la valeur valide pour ce paramètre. Pour les
paramètres booléens, la -clé
peut être spécifiée sans -valeur
correspondante, ce qui implique une valeur à true.
Par exemple, l'étiquette de langage en-US-u-kn-ks-level2
signifie une locale avec le langage Anglais dans la région US, avec des paramètres
de collation kn affecté à true et
ks affecté à level2. Ces paramètres
signifient que la collation sera insensible à la casse et traitera une séquence
de chiffres comme un nombre unique :
CREATE COLLATION mycollation5 (provider = icu, deterministic = false, locale = 'en-US-u-kn-ks-level2'); SELECT 'aB' = 'Ab' COLLATE mycollation5 as result; result -------- t (1 row) SELECT 'N-45' < 'N-123' COLLATE mycollation5 as result; result -------- t (1 row)
Voir Section 24.2.3 pour les détails et exemples supplémentaires d'utilisation des étiquettes de langage avec informations personalisées des collations pour la locale.
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 57, ou écrivez à la liste de diffusion des développeurs.
