There is a bug report in progress, as seen in this similar case
After update to Git 2.19 Git's output suddenly appeared in Russian.
I can use export LANG=en_US.UTF-8 to switch it to English back, but it's very weird.
this appears to be a bug in how brew changed its builds of Git, and also affects packages besides git.
This problem is not specific to Git.
Ævar asked if the problem also occurs with other command-line programs, and indeed it does.
For instance, I tried with 'wget' installed via brew, and it exhibits the same odd behavior.
Ævar suggested that there might be some magic special-casing English, which makes me wonder if brew builds such magic into gettext(?) or if the magic is part of
MacOS itself.
Alexey Storozhev (storoj) comments in Homebrew/homebrew-core issue 31980
I totally agree with @moonfruit that removing --with-gettext option was a mistake.
But another mistake happened and gettext support became mandatory. It affects badly if your system has one or more languages.
For example, I have en_RU locale and my git output became Russian.
That's not an option for me and I can't help with it in a normal way;
- I don't want to use
LC_LANG=en_US in my bash_profile because it will affect everything in my system,
- I don't want to make an alias like
git="LC_LANG=en_US git" either.
Another point to return --with-gettext back is the way git supports i18n.
According to INSTALL, the only way to use English is exactly NO_GETTEXT flag enabled. Otherwise, po/${lang}.po files will be used to determine available languages.
As you see, that directory does not contain "en.po" file. And if you are running git with gettext support and en_RU locale, gettext will look for following files: share/locale/{en_RU,en,ru_RU,ru}/LC_MESSAGES/git.mo. It finally finds "ru" one and uses Russian language for output which is totally unusable. I don't have any piece of development software localized in Russian.
So... rebuilding Git with NO_GETTEXT=1 flag (disabling translations) seems to be the only workaround for now (Q4 2018).
