Re: gettext, multiple Preferred languages, and English

> 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