Homebrew and Git - Lingua errata nella riga di comando


43

Ho uno strano problema: quando uso il gitcomando fornito con il pacchetto Strumenti della riga di comando, l'interfaccia sulla riga di comando è in inglese, come voglio che sia. Tuttavia, la versione installata utilizzando Homebrew utilizza il tedesco nel suo output (vivo in Germania, ma la mia lingua di sistema è impostata sull'inglese americano e il computer è stato effettivamente acquistato a Singapore, se è importante).

Credo che questo sia cambiato solo di recente. Ho dovuto dare il mio Mac per la riparazione e l'ho fatto in un negozio tedesco. Ora che ho di nuovo il mio computer ho notato che l'output di Git è in tedesco, non sono sicuro che abbiano fatto qualcosa alle impostazioni di sistema mentre lo avevano. Per quanto ne so, questa è l'unica applicazione da riga di comando che utilizza il tedesco come lingua. Ecco l'output generato dal localecomando:

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

Vorrei che Git mi parlasse in inglese. So di poter impostare l' LANGinglese ecc. E funzionerebbe (probabilmente), ma vorrei anche capire da dove potrebbe venire questo cambiamento.

Qualche idea?

EDIT : per rendere le cose più interessanti, uso un altro Mac che ho ottenuto dal lavoro. È stato acquistato in Germania, le impostazioni della lingua iniziale erano il tedesco (che ho cambiato in inglese americano) e tutto ha funzionato bene su di esso, cioè entrambe le installazioni Git (CLT e Homebrew) usano l'inglese. Le informazioni sulle impostazioni locali dal localecomando sono le stesse.


Penso di avere lo stesso problema. In esecuzione su macOS Mojave 10.14 (18A389), Homebrew 1.7.6, versione git 2.19.0 ...
Frank Lämmer,

2
Questo mi è appena successo quando sono passato a Mojave; fino ad ora ha funzionato bene. Tutte le interfacce OS X in inglese, locale C, ma sono in un paese di lingua tedesca e git mi sta parlando in tedesco. Quindi come fa Git a decidere quale lingua usare?
alexis,

Risposte:


57

Di recente, ho iniziato a osservare lo stesso comportamento, in particolare con git (e dopo l'aggiornamento a MacOS Mojave). All'inizio, ho pensato che fosse un problema con Git stesso. Quindi, ho reinstallato git con homebrew senza alcun risultato.

Tuttavia, andando alla scheda "Lingua e area geografica" in "Impostazioni" di MacOS e rimuovendo dall'elenco altre lingue non necessarie (nota: queste sono diverse dalle fonti di input della tastiera), si è verificato che git visualizzava i messaggi di output del comando nel terminale nella lingua desiderata (nel mio caso, l'inglese).

In particolare, questo problema si è verificato solo nel terminale macOS (e non, ad esempio, nel terminale VSCode).


1
Non sono ancora su Mojave, ma questo ha risolto il mio problema. E come dici tu, il terminale VSCode o Idea era in inglese, solo iterm2 era in tedesco. Ho alcune fonti di input, incluso il tedesco, poiché scrivo spesso in diverse lingue e ho bisogno dei loro caratteri speciali. Sembra (appena testato) quando aggiungo una fonte di input che aggiunge anche una lingua all'elenco "Lingua e regione", il che non è realmente necessario e causa il problema. Abbastanza strano, l'inglese era ancora in cima a quella lista ma in qualche modo scavalcato dalla seconda lingua, il tedesco. Hmm.
wujek,

1
Una cosa simile mi è successa dopo l'aggiornamento a Mojave. Il mio terminale git era in inglese ma il comando attraverso il terminale IntelliJ era in spagnolo (la mia lingua secondaria in Language & Reigon). Ho impostato esplicitamente la mia variabile d'ambiente LANG e che l'ho risolto, perché voglio lo spagnolo in Language & Reigon
Sam

@wujek il fatto che non stai usando Mojave, offre la possibilità che sia ancora un problema con il pacchetto git più recente su homebrew. Sul mio sistema, sono state apportate solo due modifiche, dopo di che ho notato il problema: aggiornamento a Mojave e aggiornamento del pacchetto git con homebrew.
Anton K,

2
Sono stato così sorpreso di vedere git in russo: D
Artem

3
L'eliminazione di una lingua non è una soluzione. Ho impostato LANG = en_US.UTF-8 ed è ancora in francese.
Walker Rowe,

10

Sto avendo lo stesso problema. Dopo l'aggiornamento homebrew git 2.17.0 -> 2.19.1, trovo che la nuova versione di git inizi a rispettare la variabile env LANG.

Se

LANG="en_US.UTF-8"

o

LANG=

git utilizzerà l'inglese.

Se, ad esempio,

LANG="zh_CN.UTF-8"

git usa il cinese.

Non ho letto i log di commit di git, ma penso che funzioni come previsto. Basta sentire un po 'strano vedere messaggi di output della riga di comando git non inglesi :)


in realtà en_ENnon è un'impostazione internazionale valida. Le versioni locali valide hanno i codici paese come gli ultimi 2 caratteri, quindi, ad esempio, en_USe en_UKsono versioni locali valide.
Walter Tross,

Non funziona per me nemmeno con la versione 2.21.0 di git da homebrew 2.1.6
Nicolas Massart,

@WalterTross In realtà non en_UKè valido, en_GB(Gran Bretagna) è quello corretto. stackoverflow.com/a/7296292/9534591
ik1ne

Giusto, e in effetti avevo già corretto correttamente la risposta di Timothy Siwula, dopo aver ricontrollato. Bisogna sempre ricontrollare con UK vs GB :-(. A proposito, è pazzesco che GB sia il codice ISO per il Regno Unito, che consiste in Gran Bretagna e Irlanda del Nord: en.wikipedia.org/wiki/ISO_3166-2: GB
Walter Tross,

questa dovrebbe essere la risposta convalidata, la rimozione delle lingue dalle impostazioni ha altri impatti.
Tsnobip,

4

Aggiungi questo al tuo .bash_profilefile: c'è un bug simile con il componente terminale di PyCharm su 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=

Dopo averlo fatto, dovrai riavviare il sistema affinché abbia effetto.

Il merito va a questo post sul blog


3

Da quello che posso dire, è un problema con GNU gettext piuttosto che un problema con Git.

Sembra che il bug sia stato corretto in GNU gettext v0.20 ; ma, a partire da questo post, Homebrew purtroppo fornisce solo v0.19.8.1 .


Ho riprodotto il problema come segue:

$ 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

il brew info gettextsembra dare informazioni su come i problemi di correzione con l'aggiunta di gettex nel percorso, ma non sono in grado di dire se devo fare questo o no ...
Nicolas Massart


0

Ho avuto lo stesso problema con Mojave e Git 2.19, ma ho appena aggiornato Git a 2.21 e ha funzionato di nuovo come previsto.


2
Sto riscontrando il problema con git 2.21.0
Walter Tross,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.