Homebrew et Git - Mauvaise langue sur la ligne de commande

43

J'ai un problème étrange: lorsque j'utilise la gitcommande fournie avec le package d'outils de ligne de commande, l'interface de la ligne de commande est en anglais, comme je le souhaite. Cependant, la version installée à l'aide de Homebrew utilise l'allemand dans sa sortie (j'habite en Allemagne, mais la langue de mon système est définie sur l'anglais américain et l'ordinateur a été acheté à Singapour, si cela est important).

Je crois que cela n'a changé que récemment. J'ai dû remettre mon Mac en réparation et je l'ai fait dans un magasin allemand. Maintenant que j'ai récupéré mon ordinateur, j'ai remarqué que la sortie de Git est en allemand, je ne sais pas s'ils ont fait quoi que ce soit aux paramètres du système pendant qu'ils l'avaient. Pour autant que je sache, c'est la seule application en ligne de commande qui utilise l'allemand comme langue. Voici la sortie générée par la localecommande:

LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

J'aimerais que Git me parle en anglais. Je sais que je peux régler LANGetc. sur l'anglais et cela fonctionnerait (probablement), mais j'aimerais également comprendre d'où vient ce changement.

Des idées?

EDIT : pour rendre les choses plus intéressantes, j'utilise un autre Mac que j'ai obtenu du travail. Il a été acheté en Allemagne, les paramètres de langue initiaux étaient l'allemand (que j'ai changé en anglais américain) et tout fonctionne bien, c'est-à-dire que les deux installations Git (CLT et Homebrew) utilisent l'anglais. Les informations locales de la localecommande sont les mêmes.

wujek
la source
Je pense que j'ai le même problème. Fonctionnant sur macOS Mojave 10.14 (18A389), Homebrew 1.7.6, git version 2.19.0…
Frank Lämmer
2
Cela m'est juste arrivé lorsque je suis passé à Mojave; jusqu'à présent, cela fonctionnait bien. Toutes les interfaces OS X en anglais, C locale, mais je suis dans un pays germanophone et git me parle en allemand. Alors , comment fait git décider quelle langue à utiliser?
alexis

Réponses:

57

Récemment, j'ai commencé à observer le même comportement, en particulier avec git (et après la mise à jour vers MacOS Mojave). Au début, je pensais que c'était un problème avec git lui-même. J'ai donc réinstallé git avec homebrew en vain.

Cependant, aller dans l'onglet "Langue et région" dans les "Paramètres" de MacOS et supprimer d'autres langues de la liste dont vous n'avez pas besoin (remarque: elles sont différentes des sources d'entrée au clavier) ont permis à git d'afficher les messages de sortie de la commande dans le terminal dans la langue souhaitée (dans mon cas, l'anglais).

Notamment, ce problème ne m'est apparu que dans le terminal macOS (et non, par exemple, le terminal de VSCode).

Anton K
la source
1
Je ne suis pas encore sur Mojave, mais cela a résolu mon problème. Et comme vous le dites, le terminal VSCode ou Idea était en anglais, juste iterm2 était en allemand. J'ai pas mal de sources d'entrée, dont l'allemand, car j'écris souvent dans différentes langues et j'ai besoin de leurs caractères spéciaux. Il semble (juste testé) que lorsque j'ajoute une source d'entrée, il ajoute également une langue à la liste «Langue et région», ce qui n'est pas vraiment nécessaire et provoque le problème. Assez étrange, l'anglais était toujours en tête de cette liste, mais en quelque sorte remplacé par la deuxième langue, l'allemand. Hmm.
wujek
1
Une chose similaire m'est arrivée après la mise à jour vers Mojave. Mon terminal git était en anglais mais le git via le terminal IntelliJ était en espagnol (ma langue secondaire dans Language & Reigon). J'ai explicitement défini ma variable d'environnement LANG et cela l'a corrigé, parce que je veux l'espagnol dans Language & Reigon
Sam
@wujek le fait que vous n'utilisez pas Mojave, permet de penser qu'il s'agit toujours d'un problème avec le plus récent paquet git sur homebrew. Sur mon système, seules deux modifications ont été apportées, après quoi j'ai remarqué le problème: mise à jour vers Mojave et mise à niveau du paquet git avec homebrew.
Anton K
2
J'ai été tellement surpris de voir git en russe: D
Artem
3
Supprimer une langue n'est pas une solution. J'ai mis LANG = en_US.UTF-8 et c'est toujours en français.
Walker Rowe
10

J'ai le même problème. Après la mise à niveau de homebrew git 2.17.0 -> 2.19.1, je trouve que la nouvelle version de git commence à respecter la variable env LANG.

Si

LANG="en_US.UTF-8"

ou

LANG=

git utilisera l'anglais.

Si, par exemple,

LANG="zh_CN.UTF-8"

git utilise le chinois.

Je n'ai pas lu les journaux de commit de git, mais je pense que cela fonctionne comme prévu. Sentez-vous un peu bizarre de voir les messages de sortie de la ligne de commande git non anglais :)

PickBoy
la source
en_ENn'est en fait pas une locale valide. Les paramètres régionaux valides ont des codes de pays comme les 2 derniers caractères, par exemple, en_USet en_UKsont des paramètres régionaux valides.
Walter Tross
Ne fonctionne pas pour moi même avec la version 2.21.0 de git de homebrew 2.1.6
Nicolas Massart
@WalterTross en_UKest également invalide, en_GB(la Grande-Bretagne) est la bonne. stackoverflow.com/a/7296292/9534591
ik1ne
D'accord, et en fait, j'avais déjà corrigé la réponse de Timothy Siwula correctement, après avoir revérifié. Il faut toujours vérifier avec UK vs GB :-(. BTW, c'est fou que GB soit le code ISO pour le Royaume-Uni, qui comprend la Grande-Bretagne et l'Irlande du Nord: en.wikipedia.org/wiki/ISO_3166-2: GB
Walter Tross
ce devrait être la réponse validée, la suppression des langues des paramètres a d'autres impacts.
tsnobip
4

Ajoutez ceci à votre .bash_profilefichier - il y a un bug similaire avec le composant terminal de PyCharm sur macOS mojave (10.14).

# locale settings, string mac/chinese/pycharm/git bug
# https://coderwall.com/p/ehvc8w/set-lang-variable-in-osx-terminal-app
export LANG="en_GB.UTF-8"
export LC_COLLATE="en_GB.UTF-8"
export LC_CTYPE="en_GB.UTF-8"
export LC_MESSAGES="en_GB.UTF-8"
export LC_MONETARY="en_GB.UTF-8"
export LC_NUMERIC="en_GB.UTF-8"
export LC_TIME="en_GB.UTF-8"
export LC_ALL=

Après cela, vous devrez redémarrer votre système pour qu'il prenne effet.

Le mérite revient à ce billet de blog

timxor
la source
3

D'après ce que je peux dire, c'est un problème avec GNU gettext plutôt qu'un problème avec Git.

Il semble que le bogue a été corrigé dans GNU gettext v0.20 ; mais, à partir de cette publication, Homebrew ne fournit malheureusement que la v0.19.8.1 .


J'ai reproduit le problème comme suit:

$ sw_vers
ProductName:    Mac OS X
ProductVersion: 10.14.4
BuildVersion:   18E226
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=
$ defaults read -g AppleLanguages
(
    "en-JP",
    "ja-JP",
    "sv-JP"
)
$ brew info gettext
gettext: stable 0.19.8.1 (bottled) [keg-only]
GNU internationalization (i18n) and localization (l10n) library
https://www.gnu.org/software/gettext/
/usr/local/Cellar/gettext/0.19.8.1 (1,934 files, 17.0MB)
  Poured from bottle on 2016-06-24 at 02:05:52
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/gettext.rb
...
$ /usr/local/Cellar/gettext/0.19.8.1/bin/msgcat --version
msgcat (GNU gettext-tools) 0.19.8.1
Copyright (c) 2001-2016 Free Software Foundation, Inc.
Licens GPLv3+: GNU GPL version 3 eller senare <http://gnu.org/licenses/gpl.html>
Detta program "ar fri programvara.  Du kan modifiera och distribuera den.
Det finns inte NAGON SOM HELST GARANTI, till den grad som lagen tillater.
Skrivet av Bruno Haible.
$ sudo filebyproc.d
CPU     ID                    FUNCTION:NAME
...
  2    957              open_nocancel:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/bin
  2    957              open_nocancel:entry msgcat /etc/localtime
  2    957              open_nocancel:entry msgcat /var/db/timezone/zoneinfo/posixrules
  2    957              open_nocancel:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/locale.alias
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/en_JP/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/en/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja_JP.eucJP/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja_JP.eucjp/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja_JP/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja.eucJP/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja.eucjp/LC_MESSAGES/gettext-tools.mo
  2    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/ja/LC_MESSAGES/gettext-tools.mo
  3    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/sv_JP/LC_MESSAGES/gettext-tools.mo
  3    171                       open:entry msgcat /usr/local/Cellar/gettext/0.19.8.1/share/locale/sv/LC_MESSAGES/gettext-tools.mo
execjosh
la source
le brew info gettextsemble donner des informations sur la façon de résoudre les problèmes en ajoutant gettex dans le chemin, mais je ne suis pas en mesure de dire si je dois le faire ou non ...
Nicolas Massart
0

J'ai eu le même problème avec Mojave et Git 2.19, mais je viens de mettre à jour le Git à 2.21 et cela a fonctionné à nouveau comme prévu.

Juan Maya
la source
2
J'ai un problème avec git 2.21.0
Walter Tross