Language file `en` missing

[Wolfgang Scherer]

Am 04.12.19 um 02:02 schrieb Mads Kiilerich:
> On 12/2/19 3:08 AM, Wolfgang Scherer wrote:
>>> Is your point that the problem would be fixed by providing an empty kallithea/i18n/en/LC_MESSAGES/kallithea.mo (and building a corresponding .po)?
>> Unfortunately, the translation file cannot be empty. Anything missing in the translation file is looked up in the next translation file of the chain.
>
>
> So ... there is no problem in the simple case with one preferred translation, and fallback to "untranslated".
Yes.
>
> But any i18n code that support multiple prioritized translations with fall-through between translations must know that if the default "untranslated" language is in the prioritized list of languages, then that language has 100% coverage even without any actual translations, and it should never look further in the list.

I heartily agree. And it actually is implemented just like that in package gettext.

> I don't think Kallithea is doing anything in that area. It rely on TurboGears (and webob and what not). If it doesn't work correctly, then it must be because we don't use these modules correctly, or because a bug in these libraries (which we then may have to work around until fixed).
Kallithea uses TurboGears (tg), which in turn uses the GNU gettext package.
> But before trying to work around in Kallithea: Exactly where is the problem?

The attached :func:`check_i18n.run.` identifies the relevant modules and functions used for translation.

1. The first question is "what is the default language?". Somehow, there is the assumption, that it would be "en". This is True for e.g., PHP: "en_US_POSIX" https://www.php.net/manual/en/class.locale.php, Android: "en" https://developer.android.com/guide/topics/resources/multilingual-support. The Android example also shows, that the resolution rules are basically arbitrary.

   But :mod:`gettext` uses "C" as the default language and **not** "en" (and is correct in doing so, since "C" is not necessarily the same as  "en"). :func:`gettext.find` also stops when "C" is found in the list of languages, just as expected.

   So :mod:`gettext` does not have a bug, just the standardized POSIX default locale C instead of the rather adhoc and arbitrary "en".

2. TurboGear has no concept of a default locale. The "C" locale is implicitely ignored, since the list of languages is fed to :func:`gettext.find` one language at a time. I.e., if "C" appears somewhere between supported locales, the list is not terminated.

   This can be considered a bug, but it is not necessarily so.

So, even if TurboGear was to be modified to recognize the default locale "C" as a termination point, that would not solve the problem of "en" not being recognized as default locale, if followed by a supported language.

Summarily, nobody can actually be blamed, however the problem still exists. The strategies to solve it are in order of (my subjective) usefulness:

1. Modify :func:`tg.i18n._gettranslator` to support a default locale ("C" **not** "en") which terminates the fallback translator chain. The default should be configurable, e.g. "i18n.default = en" (see attached :file:`check_i18n.py`). The necessary changes are minimal if not trivial. I have no idea, how welcoming the library maintainers are, but I will submit a pull request to modify the current behavior.

2. An "en" language file is supplied. This is the fastest fix. (This was probably the reason for the removed "en" language file in the first place).

3. The Accept-Language header is terminated at "en" by some middleware before the request is passed on to :mod:`tg.i18n`. This is ugly, but does not depend on a library modification.

>
> /Mads
-------------- next part --------------
A non-text attachment was scrubbed...
Name: check_i18n.py
Type: text/x-python
Size: 41621 bytes
Desc: not available
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20191204/781c410a/attachment-0001.py>