La réponse utile de Lekensteyn fonctionne très bien si vous souhaitez passer à l'anglais américain sur demande, comme l'OP l'a demandé, mais si vous souhaitez passer à une autre langue à la demande , plus de travail est nécessaire.
Avant de commencer, vous devez installer des tableaux de messages avec sudo apt-get install language-pack-<lang-tag>
, où se <lang-tag>
trouve une simple sous - étiquette de langue RTF 5646 , comme es
pour l'espagnol.
Informations de fond
GNU gettext utilitaires à base donnent la priorité à la nonstandard LANGUAGE
variable d'environnement [1]
sur les variables d'environnement définies locale POSIX LC_ALL
, LC_MESSAGES
et LANG
(dans cet ordre).
Étant donné qu'elle LANGUAGE
est définie par défaut sur les systèmes Ubuntu [2] , à savoir une sous - chaîne de la LANG
valeur qui reflète soit une simple balise de langue (par exemple, es
pour l'espagnol) ou une balise de région linguistique (par exemple, de_DE
pour la variante allemande de l'allemand), vous devez annuler ou remplacer LANGUAGE
pour que les messages d'une autre langue prennent effet. [3]
Option 1: définir LANGUAGE
Exemple : passer aux es
messages espagnols ( ) ad-hoc:
$ LANGUAGE=es ls NoSuchFile
ls: no se puede acceder a NoSuchFile: No existe el archivo o el directorio
Remarque : Une simple balise de langue telle que es
suffisante suffit, mais vous pouvez ajouter un identifiant de région (par exemple, es_AR
pour l'Argentine), et même un suffixe de jeu de caractères (par exemple, es_AR.UTF-8
).
Cependant, les messages localisés peuvent exister uniquement au niveau de la langue , et la solution de repli consiste à utiliser des messages qui correspondent à la partie de la langue ( es
, dans ce cas).
Option 2: Désactiver LANGUAGE
et définirLC_ALL
Cette solution alternative indéfinit d' LANGUAGE
abord, puis utilise la variable d'environnement locale POSIX LC_ALL
pour définir implicitement LC_MESSAGES
[4] :
$ LANGUAGE= LC_ALL=es_ES.UTF-8 ls NoSuchFile
ls: no se puede acceder a NoSuchFile: No existe el archivo o el directorio
Cette solution a l'avantage de définir tous les aspects de la localisation sur les paramètres régionaux spécifiés (comme LC_TIME
pour les formats de date / heure) et, par implicitement, le paramètre LC_MESSAGES
informe également les programmes non- GNU de la langue souhaitée.
Notez comment LC_ALL
nécessite que le nom exact et complet des paramètres régionaux, y compris le suffixe du jeu de caractères, soit efficace ( es_ES.UTF-8
) (contrairement à LANGUAGE
, pour lequel une simple balise de langue suffit (comme es
)). Il en va de même pour le réglage LC_MESSSAGES
et LANG
. La spécification d'un nom de paramètres régionaux non valide / non installé entraîne le remplacement des paramètres régionaux POSIX et donc de l'anglais américain.
Notes de bas de page
[1] Les raisons pour lesquelles la réponse de Lekensteyn fonctionne même sans annulation / remplacement LANGUAGE
sont une exception : si la LC_MESSAGES
valeur (effective) (généralement définie indirectement via LANG
ou LC_ALL
) est soit C
ou (son synonyme) POSIX
, cette valeur est respectée, quelle que soit la valeur de LANGUAGE
, si seulement. Inversement, si la LC_MESSAGES
valeur (effective) est un autre paramètre régional spécifique , LANGUAGE
est prioritaire.
[2] Cela s'applique à Ubuntu proprement dit , mais pas nécessairement aux autres versions ; Lekensteyn déclare que Kubuntu ne se couche pasLANGUAGE
.
Sans doute, neLANGUAGE
devrait pas être défini par défaut, étant donné qu'en son absence, la LC_MESSAGES
valeur impliquée par la LANG
valeur (qui détermine les paramètres régionaux actuels) est respectée.
[3] Vous pouvez également utiliser cette approche pour passer à [US] English en attribuant soit LANGUAGE=C
ou LANGUAGE=POSIX
(comme alternative à, LANG=C
/ LANG=POSIX
), bien que je ne sache pas si cela est activement reconnu ou simplement un mécanisme de secours , étant donné que ces valeurs ne ne commencez pas avec une balise de langue ; peut-être que le meilleur choix serait en_US
.
[4] Il y a un cas limite où cette approche ne fonctionne pas: essayer d'invoquer un exécutable avec un chemin - qu'il soit relatif ou absolu - ne passe PAS dans la langue spécifiée, tandis qu'un simple nom de fichier ne
LANGUAGE= LC_ALL=es_ES.UTF-8 /path/to/no_such_utility
fonctionne pas : ne fonctionne pas (génère un message dans les paramètres régionaux actuels), alors que le
LANGUAGE= LC_ALL=es_ES.UTF-8 no_such_utility
fait (génère un message d'erreur espagnol).
Si quelqu'un sait pourquoi et s'il y a une bonne raison à cela, faites-le nous savoir.
LANG
ouLANG_ALL
ne fonctionne pas pour moi, l'LANGUAGE
est encore . Voir Pourquoi le remplacement de la variable d'environnement LANG ne change-t-il pas la langue pour moi?