gnome-desktop-item-edit should change the Name= key

Thank you for your bug. The editor could change the Name= property for the local copy

It is a (way too) long standing bug for Dapper. It is very annoying for not being fixed. Isn't Dapper a Long Term Support?

Please squash this bug. Thank you.

Not critical for 7.04 release; removing milestone.

gnome-panel owns the gnome-desktop-item-edit binary that alacarte uses to edit things.

Could you describe an example to trigger the bug? What item do you try to rename and how?

The bug can be trigger in feisty with the gcalctool application for example:
Note: I do it with this language variable set: LANG="fr_CA.UTF-8"

 * right click the application menu and choose "edit menus" it open alacarte
 * choose the accessories menu and change the name of calculator for a other name
 * apply and quit in the accessories the caculator have not change is name

In the gcalctool package the fr.po file have those line:

#: ../gcalctool/gtk.c:1505 ../gcalctool.desktop.in.h:1
msgid "Calculator"
msgstr "Calculatrice"

so even if i modify the copy desktop file: .local/share/applications/gcalctool.desktop with alacarte
for my language like this:

Name[fr_CA]=zCalculatrice

gnome-desktop-item-edit still use the po file (.mo) and the name in the accessories menu is still "Calculatrice"
instead of "zCalculatrice"

so like you say gnome-desktop-item-edit could change the Name=Calculator entry in the .desktop file for
anything else and the modification will work

Cant change the menu, at all. This is really annoying.

Once again, this is a bug in gnome-panel, not alacarte.

After some investigation, it seems this bug is ubuntu specific and is a side effect of the 01_gettext-desktopfiles.patch in the glib package.

Because of this patch, if a gettext domain is given in a desktop file, the program gettext translation will be used instead of the translated string in the desktop file.

Indeed remove the "X-Ubuntu-Gettext-Domain=gcalctool" line in .local/share/applications/gcalctool.desktop and the entry will be properly translated.

To fix this, we could use the gettext translation only if no translation exists in the desktop entry file, but I don't know enough the purpose of the 01_gettext-desktopfiles.patch file to know if it is a good solution.

Sebastien, is this solution acceptable ?

BTW, what does this mentoring stuff works ?

Yann, right the gettext ubuntu change creates the issue. The desktop files have the upstream translations so your suggestion would not work correctly. Doing what the bug title suggest (change the Name= key) should work correctly. The mentoring lists easy tasks contributors can work on and where somebody is willing to review the work and upload

Sebastien, I modified gnome-panel so the Name key is changed. You will find a patch attached.
I did the same modification for the Comment key which suffers from the same problem.

However, I am not sure it's the best solution. If someone renames Name or Comment using a string which already has a gettext translation, the translation will be used instead of the user string.

Could you explain the reason for the 01_gettext-desktopfiles.patch and for the X-Ubuntu-Gettext-Domain fields ?
If upstream translations are in the desktop file, why would we need to use it ?

I found answers to these questions at https://wiki.ubuntu.com/LangpacksDesktopfiles

I suppose you already thought about that but why not try the desktop translation before the gettext one and strip all desktop translations from ubuntu packages (not a short-term solution of course).

It seems they are right now useless as gettext is already used.

some applications ship translated desktop files without having the translations in gettext those who have no translations

Ok, so we would need to strip translation at build time only if gettext translations are not available, I suppose this would be too complex.

Concerning the patch I posted, are you satisfied with it or do you have some concern about it ?

From a quick glance it looks correct, I'm busy with gutsy beta work at the moment though but I'll give it a try later this week and let you know, thank for the work on the issue

last post was in september 2007. did this ever get resolved?

Still an issue in 8.04 Hardy Heron.

Is this bug still an issue?

Sorry, I don't know, I don't use Gnome anymore, I switched to KDE4.

Le samedi 13 septembre 2008 23:31:08 Albert Cervin, vous avez écrit :
> Is this bug still an issue?

Still an issue in 8.10 Intrepid Ibex.

the bug should be fixed in karmic now the desktop translations are used before gettext, closing it now