Bug 14947 - MATE Control Center does not use translations from menu-messages
: MATE Control Center does not use translations from menu-messages
Status: NEW
Product: Mageia
Classification: Unclassified
Component: RPM Packages
: Cauldron
: i586 Linux
: Normal Severity: normal
: Mageia 6
Assigned To: Atilla ÖNTAŞ
  Show dependency treegraph
Reported: 2015-01-04 23:00 CET by Alex Loginov
Modified: 2016-06-30 09:05 CEST (History)
3 users (show)

See Also:
Source RPM:
Status comment:


Description Alex Loginov 2015-01-04 23:00:46 CET
Description of problem: if to compare translations for items from Menu and for MATE Control Center, then translations are different and missing for MATE Control Center.

Version-Release number of selected component (if applicable):

How reproducible: always

Steps to Reproduce:
1. run MATE Control Center
2. compare items translation from Menu and from MATE Control Center


Steps to Reproduce:
Comment 1 Jani Välimaa 2015-01-05 20:41:09 CET
May I ask why Mate Control Center should use translations from menu-messages?

Menu-messages is a dead pkg and we should drop it. Or alternatively find someone who will maintain and keep it in sync with our pkgs. Menu-messages has been in the same "broken" state since we forked from Mdv. We don't even have it in our git repos (or never had it in /soft in svn) that someone could update translations and create a new release tarball for it.
Comment 2 Alex Loginov 2015-01-05 21:12:30 CET
I'm working with menu-messages. I want to reanimate it.
Comment 3 Jani Välimaa 2015-01-06 08:43:49 CET
(In reply to Alex Loginov from comment #2)
> I'm working with menu-messages. I want to reanimate it.

Maybe this is something we should discuss on dev ML.

You should check that all DEs we currently ship supports translations from menu-messages.

Note that you'll need access to some mirror to get/update translations from all .desktop files we ship. This mirror should be a local one as downloading all rpms we ship from remote mirror takes time. Updating translations was easy job in Mdv days as pkg'ers had access to build nodes and thus to a local mirror.

Also note that reviving menu-messages means that all those translations you have added to .specs should be removed after translations are updated once. Then translations are centrally handled in one place.
Comment 4 Alex Loginov 2015-01-06 09:37:18 CET
KDE, MATE, LXDE uses menu-messages by default and it's enough for me. I did not test another DEs.
I found this problem with MATE Control Center for MATE, needs to patch, and MATE will be fully support menu-messages.
Comment 5 Jani Välimaa 2015-01-06 09:48:53 CET
I'd say this 'enough for me' approach is wrong. When you add such key and/or essential pkgs to the distro or start to maintain existing ones, you'll have to think about the whole distro and its users and not only yourself and what you need. We should see all DEs as equal in this case.
Comment 6 Jani Välimaa 2015-01-06 09:57:35 CET
(In reply to Jani Välimaa from comment #5)
> I'd say this 'enough for me' approach is wrong. When you add such key and/or
> essential pkgs to the distro or start to maintain existing ones, you'll have
> to think about the whole distro and its users and not only yourself and what
> you need. We should see all DEs as equal in this case.

Of course you can and should collaborate with i18n team and DE maintainers to lighten your workload. That's why I suggested discussion in dev ML.
Comment 7 Alex Loginov 2015-01-06 11:07:36 CET
DE maintainers can add patches for menu-messages (for example, it was finished for LXDE https://bugs.mageia.org/show_bug.cgi?id=14636). I use only KDE, MATE, LXDE and it works except MATE Control Center.
i18n was freeze for mga5, so mga6-mga7 is OK.

> We should see all DEs as equal in this case.
Yes, but it's too late for mga5.
Now in this part for mga5 I want to finish MATE and continue with another DEs after release. If you have time now, please welcome, but I really have no time now.

Anyway I want to use menu-messages in case if desktop file is untranslated by upstream, but in priority to translate desktop files directly in upstream (only untranslated strings should be provided by menu-messages). So, we should provide our own desktop files (Mageia is upstream for such desktop files) for direct translation and to have different Name, Comment, GenericName. If upstream is dead or author hears nothing, then Mageia should be instead of upstream for dead desktop files and provide its for direct translation also.
It's too big work and no time for mga5. But I work with Menu localization time by time.

My future plans for menu-messages:
- provide only untranslated strings for all languages, so to have different POT files for all langs.
- add strings from desktop files for translation, which are missing in /usr/share/applications in RPM (for example, desktop file from NVIDIA)
Comment 8 Atilla ÖNTAŞ 2015-01-06 19:40:44 CET
Hi. I think i missed something. Alex, do you mean this bug:


If so, i' m currently working on that. Besides matecc groups, i see anything that is untranslated, at least on my Turkish locale.
Comment 9 Alex Loginov 2015-01-06 20:44:22 CET
Atilla, hello,

No, for example, hardinfo pkg. If you look at Menu you'll see it translated. But if you open MATE Control Center, then hardinfo is untranslated.

From menu-messages for Turkish:
#: /usr/share/applications/hardinfo.desktop.in.h:1
msgid "System Profiler and Benchmark"
msgstr "Sistem Profili çıkarma ve Karşılaştırma"

So, you'll see "Sistem Profili çıkarma ve Karşılaştırma" in MATE Menu, but "System Profiler and Benchmark" in MATE Control Center.

The same situation for Comment.
Comment 10 Atilla ÖNTAŞ 2015-01-06 21:34:43 CET
Alex, if i understand you right; you propose that to patch matecc to use localized strings for untranslated 3rd party (meaning that outside from MATE De) applications desktop files which translations should be provided by menu-messages package?

If this is the case; i think we should patch the desktop files of respective applications with our translations not provide a package that contain missing translations and patchin apps itself.
Comment 11 Alex Loginov 2015-01-07 00:07:26 CET
If desktop file is untranslated for lang by upstream or by maintainer, then use translations from menu-messages. Desktop file is any desktop file (3rd party or MATE, no differences).
I'll ask Nicolas Salguero, who wrote patch for LXDE, maybe he help with MATE.
Comment 12 Nicolas Salguero 2015-01-17 10:51:37 CET

After looking at the source code of matecc, I think I cannot do what I did for LXDE menu-cache because menu-cache did not use gettext before my patch whereas matecc use gettext. So I think it is better to add translations in matecc.


Comment 13 Atilla ÖNTAŞ 2015-02-22 18:59:10 CET
I think i' m not capable to create a patch for this. Altough the file we were talking about is https://github.com/mate-desktop/mate-control-center/blob/master/libslab/application-tile.c i'm not familiar with it. May be http://svnweb.mageia.org/packages/cauldron/mate-menus/current/SOURCES/mate-menus-1.6.0-mga-l10n.patch?revision=563054&view=markup could be used but i'm not sure. Nicolas, would you mind to look them again if you can do something?
Comment 14 Nicolas Salguero 2015-03-02 09:42:33 CET

As I said in comment 12, mate control center already use gettext, not directly by including libintl.h but through Glib i18n (#include <glib/gi18n-lib.h>).

So I think the best approach is to use _() macro in source code if there are some totally missing translations and to add/update translations in already existing *.po files from mate control center pkg.


Comment 15 Alex Loginov 2015-07-12 19:01:36 CEST
Possible algorithm:
1) add menu-messages in BuildRequires.
2) convert all MO files to PO files from menu-messages
3) msgcat --use-first lang_file_from_matecc.po lang_file_from_menu_messages.po -o new_lang.po
file new_lang.po is concatenation of two files.

But we need patch: matecc does not use translations from own MO file is this case.
Comment 16 Marja van Waes 2016-06-30 09:05:42 CEST
CC'ing all packagers collectively because tarakbumba, the assignee, will be MIA for ± 11 weeks.

Note You need to log in before you can comment on or make changes to this bug.