gettext, multiple Preferred languages, and English

[Andrew Janke <floss@apjanke.net>]

Hi, Git folks,

This is a follow-up to https://marc.info/?l=git&m=154757938429747&w=2.

With the current git 2.21.0, some users, including myself, are still
having problems with git selecting the "wrong" language for localization.

This happens on macOS in the situation where:
* The user has multiple Preferred languages defined in Language & Region
system preferences
* English is set as the Primary language
* Another language, for which git has a .po translation file defined, is
set as another Preferred language, for example, Spanish
* Environment variable $LANG is unset
* git was built with gettext support enabled

In this situation, when git is run, it will use the translations from
the secondary Preferred language instead of displaying messages in
English, the Primary language.

I've seen this situation with other gettext-enabled applications before.
I believe what's happening is that when selecting the language to use,
gettext goes through the Preferred languages in order, looking for a .po
translation file for each. It does not find one for English, but it does
find one for Spanish, so it uses that, instead of falling back to the
non-translated message strings.

Some examples of this happening in the wild:
-
https://stackoverflow.com/questions/55145901/force-git-to-use-the-default-system-language/55160216
- https://github.com/Homebrew/homebrew-core/issues/37331
- https://github.com/Homebrew/homebrew-core/issues/31980

I think an easy fix for this would be to add an "en.po" translation
file, so that when gettext does its translation selection, it finds that
first for when English is the Primary language (or a Preferred language
earlier in the order than other languages), and uses it. This .po file
would be an "identity" translation where the translated strings are all
just the same as the original strings. I don't think it would even have
to be actively maintained, because for new message strings that aren't
included in the .po file, it would fall back to the non-translated input
strings, which are in English anyway, which is the desired behavior.

This would be a convenience for git users, because it would "just work"
without any modifications to the configure/build process, or requiring
users to force a $LANG setting.

Would you consider adding this?

I've put together a patch that does this:
https://github.com/apjanke/git/tree/english-dummy-translation
https://github.com/apjanke/git/commit/7e6704167018e1d47399af04230521927991811b
Not attaching a patch because it's kind of a large file. I have tested
it locally and it fixes the language selection problem for me. I'm not
sure if the appropriate thing to do is make a PR for this to the
git-l10n/git-po GitHub repo or not.

Cheers,
Andrew Janke