On 4/22/19 1:47 PM, Ævar Arnfjörð Bjarmason wrote: > > 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 <floss@xxxxxxxxxxx> 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. > Good point. I had forgotten this was OS X-specific; Linux release schedules are not relevant. (I don't know enough about language selection on Linux to know if would ever be relevant there.) There's no more general issue you're missing; as far as I know this only happens under OS X's multiple-Preferred-languages setup. Yeah, adding the workaround only on OS X sounds like it would work, and would be the more conservative thing to do. Generating a stub en.po just for OS X, and maybe just for affected versions of OS X and gettext, sounds sensible to me. The bad behavior is due to gettext's interaction with OS X's language selection, so whether it happens is probably going to depend on both the version of OS X and the version of gettext you're building against. So if you want to generate it selectively, I think you'll need to check the version of gettext (in the expectation that a future version of gettext will fix this), as well as maybe the version of OS X. This multi-language-selection behavior seems to be by design in OS X; I wouldn't expect it to change in the future. But it seems like some older versions of OS X are not affected by it. I can reproduce the bad-language-selection behavior on OS X 10.12, 10.13, and 10.14. I cannot reproduce it on OS X 10.11, which is the oldest version of OS X I can get running these days. (I'm not sure if that's due to different OS behavior, or if I'm just doing something wrong on that box.) All my testing was done with git 2.21.0 and GNU gettext 0.19.8.1. Cheers, Andrew
