Show 55 quoted lines
> On Jan 15, 2019, at 10:43:48, Nate Weaver <wevah@derailer.org> wrote:
>
>> On Jan 15, 2019, at 09:35:52, Nate Weaver <wevah@derailer.org> wrote:
>>
>>> On Sep 16, 2018, at 02:15:33, Eric Sunshine <sunshine@sunshineco.com> wrote:
>>>
>>> On Fri, Sep 14, 2018 at 10:20 PM Niko Dzhus <primenico@gmail.com> 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@evledraar.gmail.com/
>>
>> 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)