source/blog/posts/2020/11/18-language-broken-for-en.rst

   1 Title: The LANGUAGE variable is broken for English as main language
   2 Tags: en, linux, language, gettext, lang
   3
   4 The ``LANGUAGE`` environment variable can `accept multiple fallback
   5 languages`__ (at least if your commands are using ``gettext``), so if your main
   6 ``LANG`` is, say, ``es``, but you also speak ``fr``, then you can use
   7 ``LANGUAGE=es:fr``.
   8
   9 __ https://www.gnu.org/software/gettext/manual/gettext.html#The-LANGUAGE-variable
  10
  11 But what happens when you main ``LANG`` is ``en``, so for example your
  12 ``LANGUAGE`` looks like ``en:es:de``? You'll notice some message that used to
  13 be in perfect English before using the multi-language fallback now seem to be
  14 shown randomly in ``es`` or ``de``.
  15
  16 Well, it is not random. The thing is, since English tends to be the de-facto
  17 language for the original strings in a program, it looks like almost **nobody**
  18 provides an ``en`` *translation*, so when fallback is active, almost no
  19 programs will show messages in English.
  20
  21 For example, this is my Debian testing system with roughly 3.5K packages
  22 installed:
  23
  24 .. code:: console
  25
  26   $ dpkg -l |wc -l
  27   3522
  28   $ ls /usr/share/locale/en/LC_MESSAGES/ | wc -l
  29   12
  30
  31 Only 12 packages have a plain English locale. ``en_GB`` does a bit better:
  32
  33 .. code:: console
  34
  35   $ ls /usr/share/locale/en_GB/LC_MESSAGES/ | wc -l
  36   732
  37
  38 732 packages. This is still lower than both ``en`` and ``de``:
  39
  40 .. code:: console
  41
  42   $ ls /usr/share/locale/es/LC_MESSAGES/ | wc -l
  43   821
  44   $ ls /usr/share/locale/de/LC_MESSAGES/ | wc -l
  45   820
  46
  47 The weird thing is packages as basic as ``psmisc`` (providing, for example,
  48 ``killall``) and ``coreutils`` (providing, for example, ``ls``) don't have an
  49 ``en`` locale, and ``psmisc`` doesn't provide ``es``. This is why at some point
  50 it seemed like a random locale was being used. I had something like
  51 ``LANGUAGE=en_GB:en_US:en:es:de`` and I use KDE as my desktop environment. KDE
  52 seems to be correctly *translated* to ``en_GB``, so I was seeing most of my
  53 desktop in English as expected, but when using ``killall``, I got errors in
  54 German, and when using ``ls``, I got errors in Spanish.
  55
  56 If you don't provide other fallback languages, gettext will automatically fall
  57 back to the ``C`` locale, which is the original strings embedded in the source
  58 code, which are usually in English, and this is why if you don't provide
  59 fallback languages (other than English at least), all will work in English as
  60 expected. Of course if you use ``C`` in your fallback languages, before any
  61 non-English language, then they will be ignored as the ``C`` locale should
  62 always be present, so that's not an option.
  63
  64 I find it very curious that this issue has almost zero visibility. At least my
  65 searches for the issue didn't throw any useful results. I had to figure it all
  66 out by myself like in the good old pre-stackoverflow times...
  67
  68 .. note:: I know is not a typical use case, as since almost all software use
  69   English for the ``C`` locale it hardly makes any sense to use fallback
  70   languages in practice if your main language is English. But theoretically it
  71   could happen, and providing an ``en`` translation is trivial.