Building panel applet in-process breaks translations in panel main menu

[raveit65]

Expected behaviour

working translation of panel main menu

Actual behaviour

Lock screen, log out and shutdown

Steps to reproduce the behaviour

use --enable-in-process build flag

MATE general version

1.27.0

Package version

1.27.0

Linux Distribution

fedora, probably all

Link to bugreport of your Distribution (requirement)

not released yet

This is the weirdest shit ever! Tested with German, French and Spanish language. Building applet out-of-process brings back the translated menu entries.

Mate-notification-daemon package has the same issue. Package are not ready for distribution.

[raveit65]

@mate-desktop/core-team Please try to reproduce the issue in your language.

[lukefromdc]

I have NO idea how to fix this or any other fail to translate issue. If nobody else helps with this in-process builds will not be an option for any distro and will be limited to engish-speaking users able to build the applet themselves. I cannot maintain that part of the code.

[cwendling]

Classic case of a loaded module calling textdomain(), which overrides the loading process' own text domain (which is the catalogue where to look up translations from).

• No module/applet should ever call textdomain() if they are in-process (use gi18n-lib.h instead, which is almost a drop-in replacement to calling that)
• The panel could not depend on textdomain() itself, and use the same technique, not to be affected by misbehaving applets
• Maybe the panel could refuse to load a module calling textdomain(), because it's gonna cause problems (even if not in the panel itself because of the above, but 2 such applets would conflict with one another)

Or we just fix all applets that are loaded in-process without adding additional safeguarding, which is needed anyway.

[lukefromdc]

Ahh: we have another instance then of something that is out-of-process only being called from in-process. That should not be hard to fix, though someone using another language would have to test the results. This sort of thing really should throw a runtime warning just like trying to set the application name twice does.

[cwendling]

Ahh: we have another instance then of something that is out-of-process only being called from in-process.

Well, in this case there is no need to discriminate both: just use the "library" version of the API everywhere, and we're good. Again, all it requires is having GETTEXT_PACKAGE defined either on the compiler command-line or through config.h, which is trivial.

That should not be hard to fix, though someone using another language would have to test the results.

Indeed. In Python at least it's also easy to do this right -- although I think it's also easy to get it wrong.

This sort of thing really should throw a runtime warning just like trying to set the application name twice does.

Yeah ideally, but I'm not sure you can convince the libintl/libc authors to add that… who knows :shrug:

[lukefromdc]

The PR works fine here, though with locales purged and possibly other issues (even though the test package doesn't get purged until next run of synaptic or apt) any attempt to use an environmental variable to change the language of mate-panel as launched from one terminal gets

(mate-panel:15342): Gtk-WARNING **: 06:15:49.407: Locale not supported by C library.
    Using the fallback 'C' locale

[cwendling]

@lukefromdc what's in your /etc/locale.gen? (you can use grep -vE '^#|^$' /etc/locale.gen) And if all's good there, try # locale-gen again

[lukefromdc]

Only en_US.UTF-8 UTF-8 shows up as it's the only one not purged Locales I do not use myself were purged years ago to reduce the size of the filesystem and all the backup snapshots of it. Setting that one does in fact work, but reversing localepurge (which would be temporary due to space constraints) requires reinstalling EVERY localized package, and I do not have a landline for that kind of bandwidth.

I am working on one LIVE system with a backup partition and snapshots, no VMs and no bandwidth for fetching distro images etc

[cwendling]

I never used localepurge, but maybe it'd be enough to enable any other locale you might want to try that is supported by the component you want (I'd try one of de, es or fr, which should be widely available), and re-run locale-gen. Sure, it's likely that locale would be far from complete, but it might be enough to check whether a specific component works.

[lukefromdc]

Turned out uncommenting one line in /etc/locale.gen allowed regenerating one language. Starting the panel in a terminal in which export LANG=es_AR.UTF-8 had been run yielded a translated menu with the in-process volume control applet:

[cwendling]

@lukefromdc yay! Now verify that the System menu (whatever that is called in Spanish) is also still properly translated

[lukefromdc]

This is what I get in the main menu from the same way of starting the panel(another terminal's content redacted):

[raveit65]

We have national holiday in Germany, so i reached my review limit today. You have to wait. Helping in reviewing other open PRs (eg. msd gdbus) will speed up the process @cwendling