Subject: Re: gettext, multiple Preferred languages, and English

From: Ævar Arnfjörð Bjarmason <[email-masked]>
Date: Mon, 22 Apr 2019 19:47:31 +0200

On Mon, Apr 22 2019, Andrew Janke wrote:

> On 4/21/19 8:35 PM, Duy Nguyen wrote:
>> On Sun, Apr 21, 2019 at 6:40 PM Andrew Janke <[email-masked]> wrote:
>>>
>>> Hi, Git folks,
>>>
>>> This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.
>>
>> This says the problem with "en" detection has been fixed. Would
>> upgrading gettext fix it?
>>
>> You would need to upgrade something (git or gettext) and if it's
>> already fixed in gettext I don't see why we need a workaround in git.
>
> From reading the bug report, that does sound like it would fix it. But
> from what I can see, that fix hasn't made it out into a released version
> of gettext yet. I haven't downloaded the development gettext to confirm
> the fix.
>
> Looking at the gettext ftp site at https://ftp.gnu.org/pub/gnu/gettext/,
> it looks like gettext does not make frequent releases, and the last
> release was two and a half years ago. Who knows when the next release
> will be. And then it'll take longer to trickle down into Linux
> distributions and such.
>
> From your release history at https://github.com/git/git/releases, it
> seems like Git is a lot more active in making releases than gettext. So
> including this fix in Git would get it into the hands of affected users
> sooner. And it seems like a pretty low-risk change to me.
>
> Then once the new gettext release is out, their fix is confirmed, and it
> makes it out into common distros, the workaround could be removed from Git.

What does Linux distro release schedule have to do with this? Your
initial report and the linked-to bug on GNU savannah only talk about
this being an issue on OSX. Is there some more general issue I'm
missing?

People have reported issues with OSX's weird language selection in the
past. I think it makes sense to do whatever we need to hack around it as
long as it's some well-understood and OSX-only hack.

I'm paranoid that the suggestion of adding an en.po *in general* would
break stuff elsewhere. I'd be surprised if the project linked-to
upthread that used that hack is as widely ported as we are, and that
includes a lot of i18n implementations, not just GNU's.

Ultimately setlocale() is *supposed* to be a well-understood thing. You
set your preferred locale, programs have translations, the OS takes care
of it. I'm concerned that us trying to be specifically smart in git will
backfire (e.g. it's been suggested in the past to have core.language or
whatever..).

But it looks like we don't need to go there, this seems like a
workaround needed for some specific OSX version.

That can just live behind a flag and be detected in config.mak.uname,
no? And then we'd do whatever hack digs us out of that specific hole on
OSX, e.g. maybe generating an en.po *just* there, and just for that list
of known broken version(s) of OSX.