--Nate Weaver (Wevah) > On Jan 15, 2019, at 10:43:48, Nate Weaver <wevah@xxxxxxxxxxxx> wrote: > >> On Jan 15, 2019, at 09:35:52, Nate Weaver <wevah@xxxxxxxxxxxx> wrote: >> >>> On Sep 16, 2018, at 02:15:33, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote: >>> >>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus <primenico@xxxxxxxxx> wrote: >>>> Looks like the issue appeared after updating git from brew. >>>> >>>> A quick search revealed that brew changed how it builds git recently. >>>> I think, it just didn't include i18n by default before, so I never >>>> noticed this. >>>> >>>> Anybody here familiar enough with the build process and dependencies >>>> of git to pinpoint what exactly is causing this and how to fix it?... >>> >>> This problem is not specific to Git. Earlier in the thread, Ævar >>> asked[1] 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. >>> >>> [1]: https://public-inbox.org/git/87a7ojlp31.fsf@xxxxxxxxxxxxxxxxxxx/ >> >> I discovered that moving/renaming /usr/local/share/locale made this >> issue go away for me. While 'de' and 'fr' have a git.mo file in their >> LC_MESSAGES subdirectory, there is no 'en' directory. >> >> If I copy the 'fr' version to a newly-created 'en' directory, then all my >> git output is in French; my language order in System Preferences is >> English (US) -> German -> Japanese. >> >> Not sure if this is gettext's or macOS's issue. >> >> --Nate Weaver (Wevah) > > Upon further digging, this is an issue in gettext's code on macOS: > The function _nl_language_preferences_default (in langprefs.c) specifically > breaks early when it sees the literal string "en" in the list (from the > "AppleLanguages" defaults key), but not when it gets "en-US", etc. > > I.e., it doesn't check for a prefix. > > This can be fixed (though there might be a better way) simply by replacing > both instances of > > if (strcmp (buf, "en") == 0) > > with > > if (strncmp (buf, "en", 2) == 0) > > in gettext's langprefs.c. Nevermind: I've been informed that this has already been fixed on the git trunk for gettext, and will be in the next release. (See: https://savannah.gnu.org/bugs/?49560)
