Compatibilité :	3.5.0
Éditions :
Plateformes :

Cette propriété spécifie la langue de sortie du Wrapper.

Sous Windows, la valeur doit être l'une des langues installées. Veuillez consulter la liste des langues prises en charge sur le site Web de Microsoft. La notation courte (étiquette de langue) est préférée et peut être écrite avec un '_' au lieu d'un '-' pour une compatibilité croisée avec les systèmes Unix.

Sur les systèmes basés sur UNIX, la valeur doit être la partie valide 'language[_territory]' d'une locale installée.

Pour obtenir les locales installées et disponibles sur les systèmes UNIX, veuillez exécuter « locale -a ».

locale -a
C
de_AT.utf8
de_BE.utf8
de_CH.utf8
de_DE.utf8
de_DE@euro
de_DE.iso885915@euro
de_LI.utf8
de_LU.utf8
en_AG
en_AU.utf8
en_BW.utf8
en_CA.utf8
en_DK.utf8
en_GB.utf8
en_HK.utf8
en_IE.utf8
en_IN
en_NG
en_NZ.utf8
en_PH.utf8
en_SG.utf8
en_US.utf8
en_ZA.utf8
en_ZW.utf8
ja_JP.eucjp
ja_JP.shiftjis
ja_JP.utf8
POSIX

Vous n'avez besoin de définir que la partie 'language[_territory]' pour cette propriété. L'encodage sera défini dans les propriétés wrapper.lang.windows.encoding ou wrapper.lang.unix.encoding.

wrapper.lang=ja_JP

À partir de la version 3.5.28 du Wrapper, la propriété wrapper.lang peut également être définie avec les valeurs suivantes :

• DESKTOP pour la langue de l'interface utilisateur.
• SYSTEM pour la langue du système (couramment appelée « Langue pour les programmes non Unicode »).

Sous Windows, la valeur par défaut est DESKTOP. Avant la version 3.5.28, la langue était déterminée à l'aide de l'identifiant de langue des paramètres de format régional.

Sur les systèmes d'exploitation basés sur UNIX, 'DESKTOP' et 'SYSTEM' sont tous deux considérés comme des valeurs par défaut et résolus comme la langue de la session en cours.

Depuis la version 3.5.31, le Wrapper essaiera d'utiliser une casse différente (par exemple 'JA_JP' au lieu de 'ja_JP') si aucune correspondance exacte n'a pu être trouvée lors de la recherche parmi les langues installées sur le système. Cela est fait pour améliorer la portabilité, car des caractères minuscules ou majuscules peuvent être utilisés pour une même langue selon la plateforme. Lors de l'exécution sur un seul serveur, il est toutefois recommandé de définir la valeur exactement telle qu'elle est renvoyée par la commande 'locale'.

Il est également possible de spécifier un modificateur (par ex. @euro) après la langue. Si wrapper.lang.encoding est également défini, le modificateur sera automatiquement ajouté après l'encodage lors de la définition de la locale. En général, il ne devrait pas être nécessaire d'ajouter le modificateur, car le Wrapper recherche également parmi les locales en ignorant les modificateurs si aucune correspondance exacte n'a pu être trouvée.

Compatibilité :	3.5.0 (Deprecated as of 3.5.35)
Éditions :
Plateformes :

Cette propriété spécifie l'encodage du processus Wrapper qui est utilisé pour lire la sortie de la JVM et pour écrire les sorties de journal. L'encodage sélectionné doit être installé sur le système d'exploitation afin de pouvoir l'utiliser. Lorsque le Wrapper ne peut pas définir l'encodage, il se rabat sur l'encodage de l'environnement depuis lequel il a été lancé.

Compatibilité :	3.5.35
Éditions :
Plateformes :

Cet ensemble de propriétés a été introduit dans la version 3.5.35 pour configurer l'encodage du processus Wrapper (utilisé pour lire la sortie de la JVM et pour écrire les sorties de journal) de manière multiplateforme.

Alors que les systèmes Unix utilisent souvent la même syntaxe pour les encodages, Windows utilise des pages de codes au lieu de noms. Si le Wrapper est destiné à s'exécuter sur les deux plateformes, vous pouvez utiliser à la fois wrapper.lang.unix.encoding et wrapper.lang.windows.encoding dans votre fichier de configuration pour définir l'encodage de chaque plateforme.

Les systèmes Unix utilisent souvent la même syntaxe pour les encodages. Parfois, la casse ou la ponctuation peut différer (par ex. 'UTF-8' vs 'utf8'), mais le Wrapper résoudra automatiquement ces cas si aucune correspondance exacte n'a pu être trouvée. Cependant, certains systèmes d'exploitation utilisent des noms spécifiques à la plateforme et il peut être utile de cibler ces encodages avec des propriétés dédiées. Cela est possible en utilisant l'un des noms de plateforme listés ci-dessous. Si la propriété pour une plateforme Unix n'est pas spécifiée, la valeur par défaut sera la valeur de wrapper.lang.unix.encoding.

Les valeurs prises en charge pour <platform> sont :

• windows (voir wrapper.lang.windows.encoding)

• unix (voir wrapper.lang.unix.encoding)

• aix

• freebsd

• hpux

• linux

• macosx

• solaris

• zos

wrapper.lang=ja_JP
wrapper.lang.windows.encoding=20932
wrapper.lang.unix.encoding=eucJP
wrapper.lang.aix.encoding=IBM-eucJP

wrapper.lang.windows.encoding

Compatibilité : 3.5.35 Éditions : Plateformes : Cette propriété a été ajoutée dans la version 3.5.35 pour apporter la prise en charge des encodages sous Windows. La valeur par défaut est 'ANSI', qui fait référence à la page de codes ANSI par défaut du système d'exploitation. Il s'agit de la même valeur que celle utilisée par défaut par la JVM. Définir cette propriété sur une autre valeur aura deux effets : - Premièrement, le Wrapper transmettra l'encodage à la JVM en ajoutant la propriété système file.encoding à la liste des arguments de la JVM. Cela garantit que la JVM et le Wrapper écrivent et lisent respectivement en utilisant le même encodage. - Deuxièmement, la locale du processus Wrapper sera mise à jour afin que toutes les sorties du Wrapper puissent être écrites dans le fichier journal en utilisant le même encodage. La valeur de cette propriété peut être définie sur l'un des identifiants de pages de codes Windows. Notez toutefois que le Wrapper restreindra certaines valeurs lorsque la page de codes ne peut pas être utilisée pour écrire dans la console (voir l'avertissement en bas de cette section), ou lorsque la page de codes est connue pour être incompatible avec la langue configurée. À partir de la version 3.5.35, la compatibilité n'est vérifiée que pour les langues fournies avec le Wrapper (c'est-à-dire l'anglais, l'allemand et le japonais) : - L'anglais est compatible avec toutes les pages de codes car il ne contient que des caractères ANSI. - L'allemand prend en charge les pages de codes suivantes : 437, 850, 1141, 1250, 1252, 20106, 20273, 28591, 28592, 65000 et 65001 (UTF-8) - Le japonais prend en charge les pages de codes suivantes : 932, 10001, 20290, 20932, 21027, 50220, 50221, 50222, 50930, 50931, 50939, 51932, 65000 et 65001 (UTF-8) AVERTISSEMENT Contrairement aux systèmes Unix, Windows ne vérifie pas la compatibilité entre une page de codes et une langue lors de la définition d'une locale. Cela signifie qu'une langue (autre que celles listées ci-dessus) associée à une mauvaise page de codes peut entraîner des sorties illisibles, sans que le Wrapper puisse le savoir. Par défaut, la localisation du Wrapper est déterminée à l'aide de la langue de l'interface utilisateur, qui peut varier selon la machine. Pour garantir un encodage correct sur les différentes plateformes, wrapper.lang.windows.encoding doit être défini sur 'ANSI' (ou laissé à la valeur par défaut), 'OEM' ou 'UTF-8' si wrapper.lang est défini sur 'DESKTOP' ou 'SYSTEM'. Exemple : (définir l'encodage sur eucJP) wrapper.lang=ja_JP wrapper.lang.windows.encoding=20932 Il est également possible de spécifier 'UTF-8', 'ANSI' ou 'OEM'. Les deux derniers correspondent à la page de codes ANSI du système d'exploitation et à la page de codes OEM du système d'exploitation. Exemple : (définir l'encodage sur UTF-8) wrapper.lang=de_DE wrapper.lang.windows.encoding=UTF-8 Notez que certains encodages comme UTF-8 contiennent des caractères codés sur plus de 2 octets. La locale du processus Wrapper ne peut pas être définie avec une page de codes DBCS, mais le Wrapper fonctionne en interne en Unicode et appliquera une conversion pour écrire la sortie du journal dans le bon encodage. AVERTISSEMENT Le Wrapper peut utiliser deux modes différents lors de l'écriture de sa sortie dans la console. Ces modes peuvent être contrôlés avec la propriété wrapper.console.direct. Lorsqu'il est défini sur TRUE, ce qui est la valeur par défaut, la console fonctionne en Unicode et toute conversion à partir de la valeur de wrapper.lang.windows.encoding sera prise en charge. Cependant, vous devez vous assurer que la police de la console prend en charge les caractères de la langue. La police peut être modifiée depuis la fenêtre « Propriétés » de la console. Lorsque wrapper.console.direct est défini sur FALSE, le Wrapper utilisera stdout et stderr, ce qui nécessite que toutes les sorties soient écrites dans la page de codes de la console afin qu'elles puissent être décodées et affichées correctement de l'autre côté des flux. Dans ce mode, toute valeur de wrapper.lang.windows.encoding qui n'est pas compatible avec la page de codes de la console sera rejetée. NOTE En plus de définir l'encodage de la sortie du Wrapper, wrapper.lang.windows.encoding est également utilisé lors de la lecture de la sortie de la JVM. S'il est laissé à sa valeur par défaut (ANSI), les propriétés système 'file.encoding', 'sun.stdout.encoding' et 'sun.stderr.encoding' peuvent être utilisées pour spécifier un encodage différent que le Wrapper utilisera pour lire la sortie de la JVM. Cependant, si wrapper.lang.windows.encoding spécifie un encodage autre que 'ANSI', les propriétés système ne seront pas acceptées dans les propriétés wrapper.java.additional.*, car le Wrapper devrait également les utiliser. Dans une telle situation, le Wrapper considérera la configuration comme invalide et s'arrêtera. Il vous sera demandé de choisir entre les propriétés du Wrapper et les propriétés système.

wrapper.lang.unix.encoding

Compatibilité : 3.5.35 Éditions : Plateformes : Cette propriété a été introduite dans la version 3.5.35 pour remplacer la propriété dépréciée wrapper.lang.encoding. Comme wrapper.lang.encoding, la valeur par défaut est l'encodage de la locale définie pour la session qui a lancé le Wrapper. Avant d'utiliser l'encodage, le Wrapper s'assurera toujours que la combinaison de la langue et de l'encodage configurés existe en tant que locale installée sur le système, et que toutes les conversions depuis et vers l'encodage configuré sont prises en charge. Si la configuration est correcte, la locale (langue et encodage) du processus Wrapper sera mise à jour, sinon le Wrapper tentera de combiner la langue configurée avec l'encodage de la session qui a lancé le Wrapper, ou à défaut, ne mettra pas à jour la locale. Exemple : (définir l'encodage sur eucJP) wrapper.lang=ja_JP wrapper.lang.unix.encoding=eucJP Si vous utilisez la commande 'locale -a' pour lister toutes les locales installées du système, vous remarquerez peut-être que certaines d'entre elles n'ont pas d'encodage spécifié dans leur nom descriptif. En fait, ces locales ont un encodage par défaut qui peut être affiché en utilisant la commande suivante : Exemple : (afficher l'encodage par défaut) LANG=de_DE@euro locale charmap ISO-8859-15 Afin que le Wrapper utilise une locale avec un encodage par défaut, il est nécessaire de définir wrapper.lang.encoding sur la valeur de l'encodage par défaut. Exemple : (définir une locale avec son encodage par défaut) wrapper.lang=de_DE@euro wrapper.lang.unix.encoding=ISO-8859-15 NOTE Sur certaines plateformes, vous devrez changer la locale avant d'exécuter 'locale charmap'. Sous macOS, 'locale charmap' renverra une chaîne vide lors de la requête de l'encodage par défaut d'une locale. Dans ce cas, l'encodage est supposé être UTF-8. NOTE Lors de la définition d'une locale, certaines plateformes (Linux, AIX) ignoreront les tirets canoniques, la ponctuation et la casse dans la notation de l'encodage. Par exemple, UTF-8 est équivalent à utf8. D'autres plateformes exigeront que les encodages correspondent strictement (Solaris, FreeBSD, HP-UX). Enfin, certaines plateformes exigeront que les tirets et la ponctuation correspondent, mais pas nécessairement la casse (macOS, ZOS). AVERTISSEMENT Afin d'afficher correctement les sorties de journal, l'encodage configuré doit correspondre à l'encodage du terminal. Le Wrapper n'a aucun moyen de connaître l'encodage du terminal, car il est généralement spécifié par une option de l'émulateur de terminal et non par une variable de locale. Par exemple, l'encodage du terminal Gnome peut être modifié depuis le menu en sélectionnant : Terminal -> Définir l'encodage des caractères. Contrairement à Windows, la compatibilité entre une langue et l'encodage est automatiquement vérifiée par le fait qu'il n'est possible de définir une locale que parmi celles installées sur le système, une locale installée étant un ensemble où l'encodage est approprié pour les paramètres de langue et de région qu'il représente. Une autre différence avec Windows est que le Wrapper n'a généralement pas besoin de transmettre l'encodage à la JVM (via file.encoding), car la JVM utilise automatiquement l'encodage de la locale du processus Wrapper. Cependant, depuis la version 3.5.35, l'encodage de sortie de la JVM et l'encodage par défaut peuvent être définis sur des valeurs différentes en utilisant wrapper.jvm.encoding, auquel cas le Wrapper devra ajouter les deux encodages aux arguments utilisés lors du lancement de la JVM. Pour cette raison, il n'est pas autorisé d'utiliser wrapper.jvm.encoding conjointement avec 'file.encoding', 'sun.stdout.encoding' ou 'sun.stderr.encoding' dans les propriétés wrapper.java.additional.* (voir wrapper.jvm.encoding pour plus de détails).

Compatibilité :	3.5.0
Éditions :
Plateformes :

Cette propriété définit l'emplacement des fichiers de langue. La valeur par défaut est "../lang".

wrapper.lang.folder=lang

Veuillez noter que les chemins relatifs sont relatifs à l'emplacement du binaire du Wrapper, et non à l'emplacement depuis lequel la commande a été lancée ni à l'emplacement du fichier de configuration.

Compatibilité :	3.5.0
Éditions :
Plateformes :

Cette propriété définit le domaine des fichiers mo du binaire et de la bibliothèque. Si vous souhaitez renommer les fichiers wrapper_XX.mo et wrapperjni_XX.mo, vous devez définir cette propriété en conséquence.

wrapper.lang.domain=myapp

Cela amènera le Wrapper à rechercher les fichiers myapp_XX.mo ou myappjni_XX.mo lors du chargement des ressources linguistiques.