47

I have a strange issue - when I use the git command which comes with the Command Line Tools package, the interface on the command-line is in English, as I want it to be. However, the version installed using Homebrew uses German in its output (I live in Germany, but my system language is set to US English and the computer was actually bought in Singapore, if it matters).

I believe this changed only recently. I had to give my Mac for repair and did so in a German store. Now that I have my computer back I noticed that Git's output is in German, not sure if they did anything to the system settings while they had it. As far as I know, this is the only command-line application that uses German as its language. Here is the output generated by the locale command:

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

I would like to have Git talk to me in English. I know I can set the LANG etc. to English and it would (probably) work, but I would also like to understand where this change may be coming from.

Any ideas?

EDIT: to make things more interesting, I use another Mac that I got from work. It was bought in Germany, the initial language settings were German (which I changed to US English) and everything works fine on it, i.e. both Git installations (CLT and Homebrew) use English. Locale information from the locale command is the same.

3
  • I think I am having the same issue. Running on macOS Mojave 10.14 (18A389), Homebrew 1.7.6, git version 2.19.0 … Commented Sep 28, 2018 at 9:56
  • 2
    This just happened to me when I upgraded to Mojave; until now it worked fine. All OS X interfaces in English, C locale, but I'm in a German-speaking country and git is talking to me in German. So how does git decide what language to use?
    – alexis
    Commented Nov 22, 2018 at 8:26
  • "I would like to understand where this change may be coming from" If that's the case, you should accept this answer. The one you accepted just provides a workaround which might not be useful for people who need multiple language support.
    – miken32
    Commented Nov 14, 2021 at 16:25

8 Answers 8

4

From what I can tell, it's a problem with GNU gettext rather than a problem with Git.

It looks like the bug was fixed in GNU gettext v0.20; but, as of this posting, Homebrew unfortunately provides only v0.19.8.1.


I reproduced the problem as follows:

$ 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
2
  • the brew info gettext seems to give infos about how to fix issues by adding gettex in path, but I'm not able to tell if I should do this or not... Commented Jun 17, 2019 at 9:08
  • Nice catch; MacPorts has the same ancient version of the gettext lib and suffers from the same problem. trac.macports.org/ticket/58526
    – miken32
    Commented Nov 14, 2021 at 16:22
59

Recently, I've started to observe the same behavior, particularly with git (and after updating to MacOS Mojave). At first, I thought it's an issue with git itself. So, I've reinstalled git with homebrew to no avail.

However, going to "Language & Region" tab in the MacOS "Settings", and removing other languages from the list that you don't need (note: these are different from the keyboard input sources) resulted in git displaying the command output messages in terminal in the desired language (in my case, English).

Notably, this problem occurred to me only in the macOS terminal (and not, e.g., VSCode's terminal).

10
  • 1
    I'm not yet on Mojave, but this fixed my issue. And as you say, VSCode or Idea terminal was in English, just iterm2 was in German. I do have quite a few input sources, including German, as I often write in different languages and need their special characters. It seems (just tested) when I add an input source it also adds a language to 'Language & Region' list, which is not really necessary and causes the issue. Strange enough, English was still on top of that list but somehow overridden by the second language, German. Hmm.
    – wujek
    Commented Sep 29, 2018 at 22:09
  • 1
    A similar thing happened to me after updating to Mojave. My Terminal git was in English but the git through the IntelliJ terminal was in Spanish (my secondary language in Language & Reigon). I explicitly set my LANG environment variable and that fixed it, because I want Spanish in Language & Reigon
    – Sam
    Commented Sep 29, 2018 at 22:13
  • @wujek the fact that you’re not using Mojave, allows for possibility that it is still might be an issue with the most recent git package on homebrew. On my system, only two changes have been made after which I’ve noticed the issue: update to Mojave and upgrade of the git package with homebrew.
    – Anton K
    Commented Sep 30, 2018 at 6:02
  • 2
    I was so surprised to see git in Russian :D
    – Artem
    Commented Nov 8, 2018 at 17:10
  • 3
    Deleting a language is not a solution. I set LANG=en_US.UTF-8 and it's still in French. Commented Jan 10, 2019 at 16:13
12

I'm having the same issue. After homebrew upgrade git 2.17.0 -> 2.19.1, I find that the new git version starts to respect LANG env variable.

If

LANG="en_US.UTF-8"

or

LANG=

git will use English.

If, e.g.,

LANG="zh_CN.UTF-8"

git use Chinese.

I haven't read the commit logs of git, but I think it's working as intended. Just feel a little odd to see non-English git command line output messages :)

5
  • actually en_EN is not a valid locale. Valid locales have country codes as the last 2 characters, so, e.g., en_US and en_UK are valid locales. Commented Mar 29, 2019 at 14:30
  • Does not work for me even with git version 2.21.0 from homebrew 2.1.6 Commented Jun 17, 2019 at 9:07
  • @WalterTross Actually en_UK is also invalid, en_GB(Great Britain) is the correct one. stackoverflow.com/a/7296292/9534591
    – ik1ne
    Commented Aug 6, 2019 at 0:46
  • Right, and in fact I had already fixed the answer by Timothy Siwula correctly, after double-checking. One always has to double-check with UK vs GB :-(. BTW, it's crazy that GB is the ISO code for the UK, which consists of Great Britain and Northern Ireland: en.wikipedia.org/wiki/ISO_3166-2:GB Commented Aug 6, 2019 at 5:34
  • this should be the validated answer, removing languages from the settings has other impacts.
    – tsnobip
    Commented Dec 23, 2019 at 18:32
4

Add this to your .bash_profile file-- there's a similar bug with PyCharm's terminal component on 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=

After doing this, you'll need to restart your system for it to take effect.

Credit goes to this blog post

0
1

Workaround : Deleting all other prefered languages.

But still an open issue for that purpose: https://youtrack.jetbrains.com/issue/IDEA-216039

1

On my machine, it seems git is looking for the system AppleLanguages defined in /Library/Preferences/.GlobalPreferences.plist instead of the one defined in your user's preferences in ~/Library/Preferences/.GlobalPreferences.plist. If your mac came with a certain language by default, the system's AppleLanguages will be that language and none other.
To apply your user's language setting system-wide, you need to press the little gear in the bottom right of the preferred languages picker and press "Apply to Login Window".

2
  • 1
    Perhaps add a comment when downvoting, this is a perfectly fine answer and the only way I found to fix this issue on my system.
    – Atemu
    Commented Sep 15, 2021 at 13:19
  • Yeah, downvoting without a comment is not helpful, and your answer is reasonable. I just upvoted you for this reason. Commented Apr 6, 2023 at 20:47
1

In my case, it seems that an iterm2 upgrade caused git to forget English https://gitlab.com/gnachman/iterm2/-/issues/11597

To bypass it, https://gitlab.com/gnachman/iterm2/-/issues/11597#note_1939676707 worked for me:

go to iterm2 preferences -> Profile -> terminal and under the Environment select USE CUSTOM LOCALE and then select ENGLISH(UNITED STATES UTF-8).

0

I had the same issue with Mojave and Git 2.19, but I just updated the Git to 2.21 and it worked as expected again.

1
  • 2
    I'm having the problem with git 2.21.0 Commented Mar 29, 2019 at 14:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .