Not respecting LANGUAGE variable properly (default language).

changed the description

I don't think there's a bug here. This behavior comes from XfceRc, which is our implementation of read/write `.desktop' files. Glib's is GKeyFile.

In both cases, if a locale specified in $LANGUAGE is not found in a .desktop file, then we try the next one, until we run out. However, neither en_US nor C are found in most .desktop files, unlike de_DE or fr_FR for example, so it's the locale that's chosen in the end.

You can check this with this code:

  XfceRc *rc = xfce_rc_simple_open ("/usr/share/applications/firefox.desktop", TRUE);
  xfce_rc_set_group (rc, G_KEY_FILE_DESKTOP_GROUP);
  g_printerr ("%s\n", xfce_rc_read_entry (rc, G_KEY_FILE_DESKTOP_KEY_COMMENT, NULL));
  xfce_rc_close (rc);

  GKeyFile *file = g_key_file_new ();
  g_key_file_load_from_file (file, "/usr/share/applications/firefox.desktop", G_KEY_FILE_NONE, NULL);
  g_printerr ("%s\n", g_key_file_get_locale_string (file, G_KEY_FILE_DESKTOP_GROUP, G_KEY_FILE_DESKTOP_KEY_COMMENT, NULL, NULL));
  g_key_file_free (file);

Replacing en_US with en_GB, for example, produces the desired translation. It also seems to comply with the specification.

Huh, that's really bad behavior, then, even if it's what's specified. Reading that spec you linked to, I do feel like it's a bit ambiguous for this case. I would feel like keys without a [$LANG] suffix should implicitly be considered [C] or even [en_US].

Do we know how gettext behaves in this case? Regardless of the spec (which, as I said, seems very ambiguous and underspecified here), I feel like the key file semantics should be the same as whatever gettext would do. I think consistency is the most important thing here; users care that things behave consistently, not that a spec is followed to the letter.

It's a different thing. If a key has no [$LANG] entry, then the base entry key= is chosen, regardless of its contents. The question here is what to do when en_US or C is requested, and no entry in this locale is specified. Should we fall back on the key= base entry? I don't know... obviously, that's not what glib does either.

Right, I get it, and that's what I'm suggesting: if C or en_US is specified, then we should always prefer the bare Key=.

But really I think what's important is what gettext does here. If gettext selects C/en_US in this particular setup (that is, when a de_DE .mo file is available, but there is no .mo file for C or en_US), then I think XfceRc should as well (and we should file an issue against GKeyFile).

The bit that seems extra interesting in this case is that the reporter here also has LC_MESSAGES set -- without reading the docs/spec, I would think that LC_MESSAGES, since it's more specific than LANG or LANGUAGE, would take precedence, so in that case, everything should be in English. And, indeed, the spec you linked to only mentions LC_MESSAGES, and doesn't reference LANG or LANGUAGE at all. If I set things up like the reporter, I get:

$ export LANG=en_US.UTF-8
$ export LANGUAGE=en_US:C:de_DE
$ export LC_MESSAGES=en_US.UTF-8
$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US:C:de_DE
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

So my reading of the spec is taht we should just be looking at LC_MESSAGES. Here it's en_US, so we look for Key[en_US]=. We don't find it, so we should use Key=. And that's it. LANG and LANGUAGE aren't relevant.

But really I think what's important is what gettext does here. If gettext selects C/en_US in this particular setup (that is, when a de_DE .mo file is available, but there is no .mo file for C or en_US), then I think XfceRc should as well (and we should file an issue against GKeyFile).

I think that's what gettext does, but it needs to be better tested with the appropriate .mo files. I'll see tomorrow.

So my reading of the spec is taht we should just be looking at LC_MESSAGES. Here it's en_US, so we look for Key[en_US]=. We don't find it, so we should use Key=. And that's it. LANG and LANGUAGE aren't relevant.

I don't think so: we added support for LANGUAGE in cycle 4.19 because gettext (and GKeyFile) support it. The spec doesn't mention it, but that's because it's incomplete in terms of environment variables.

I'd like to link to the following bit of gettext's documentation which discusses the precedence of the locale environment variables. LANGUAGE actually has highest precedence.

Also, I want to add the following thoughts (should have better explained probably):

I referred to the bare categories of the Application Menu (not to any particular desktop entries, although the behavior a user expects is probably the same). For example, with the above setup, you'd click on "Applications" in xfce-panel, which then opens up the Applications Menu containing German entries. I find, especially the diverging behavior between xfce's components might confuse the user (as it did to me).
How would we tell garcon in the current situation: "Do always use (US) English language, except if not available (in the latter case, use the first available one from LANGUAGE)."? (This is admittedly an unlikely scenario, however for particular software possible).

I think that's what gettext does, but it needs to be better tested with the appropriate .mo files. I'll see tomorrow.

Yes, it seems that gettext does work like that, but only for C, not for en_US. I'll open an issue on glib and see what they say.

I referred to the bare categories of the Application Menu (not to any particular desktop entries, although the behavior a user expects is probably the same).

It also comes from .desktop files, although in this case they have a different extension.

How would we tell garcon in the current situation: "Do always use (US) English language, except if not available (in the latter case, use the first available one from LANGUAGE)."? (This is admittedly an unlikely scenario, however for particular software possible).

There is in fact a distinction between C and en_US. If no en_US "translation" exists (.mo file for gettext, key[en_US]= for .desktop files), then the following locale in $LANGUAGE is tried, which seems to be the expected behavior.

On the other hand, for C, gettext uses the original string, and therefore effectively ignores the other locales in $LANGUAGE, so LANGUAGE=C:something is equivalent to LANGUAGE=C, apparently.

As it stands, to get C for .desktop files, you need to do LANGUAGE=C, or LANG=C, or another stronger version (LC_ALL=C).

Glib issue: https://gitlab.gnome.org/GNOME/glib/-/issues/3578

closed

added 3. Not a Bug label

added 5. Launcher / .desktop File label

I'm pretty convinced we should honor C as gettext, me too, let's reopen that.

reopened

removed 3. Not a Bug label

mentioned in merge request !62 (merged)

See !62 (merged) for a patch corresponding to what I proposed for glib and which was merged: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4480.

changed milestone to %4.20.1

assigned to @Tamaranch

closed with commit bd1538ad

Not respecting LANGUAGE variable properly (default language).

Designs

Child items ...

Activity