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.
