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:
Release (media or process) =>
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.
I'm working with menu-messages. I want to reanimate it.
(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.
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.
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.
(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.
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)
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.
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:
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.
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.
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.
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.
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?
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.
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.
CC'ing all packagers collectively because tarakbumba, the assignee, will be MIA for Â± 11 weeks.
Reassigning to all packagers collectively as the original maintainer is not available anymore (thanks for all your work Atilla!).