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 espour l'espagnol.
Informations de fond
GNU gettext utilitaires à base donnent la priorité à la nonstandard LANGUAGEvariable d'environnement [1]
sur les variables d'environnement définies locale POSIX LC_ALL, LC_MESSAGESet LANG(dans cet ordre).
Étant donné qu'elle LANGUAGEest définie par défaut sur les systèmes Ubuntu [2] , à savoir une sous - chaîne de la LANGvaleur qui reflète soit une simple balise de langue (par exemple, espour l'espagnol) ou une balise de région linguistique (par exemple, de_DEpour la variante allemande de l'allemand), vous devez annuler ou remplacer LANGUAGEpour que les messages d'une autre langue prennent effet. [3]
Option 1: définir LANGUAGE
Exemple : passer aux esmessages 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 essuffisante suffit, mais vous pouvez ajouter un identifiant de région (par exemple, es_ARpour 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 LANGUAGEet définirLC_ALL
Cette solution alternative indéfinit d' LANGUAGE abord, puis utilise la variable d'environnement locale POSIX LC_ALLpour 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_TIMEpour les formats de date / heure) et, par implicitement, le paramètre LC_MESSAGESinforme également les programmes non- GNU de la langue souhaitée.
Notez comment LC_ALLné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_MESSSAGESet 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 LANGUAGEsont une exception : si la LC_MESSAGESvaleur (effective) (généralement définie indirectement via LANGou LC_ALL) est soit Cou (son synonyme) POSIX, cette valeur est respectée, quelle que soit la valeur de LANGUAGE, si seulement. Inversement, si la LC_MESSAGESvaleur (effective) est un autre paramètre régional spécifique , LANGUAGEest 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_MESSAGESvaleur impliquée par la LANGvaleur (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=Cou 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_utilityfonctionne 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_utilityfait (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.
LANGouLANG_ALLne fonctionne pas pour moi, l'LANGUAGEest encore . Voir Pourquoi le remplacement de la variable d'environnement LANG ne change-t-il pas la langue pour moi?