Comment # 23 on bug 904524 from Wolfgang Bauer

(In reply to Karl Ove Hufthammer from comment #22)

> No, that doesn���t work with the example I mentioned. The translations are
> stored in ���Name���, but the source code mentioned in
> https://techbase.kde.org/Development/Tutorials/Localization/
> i18n_Challenges#Translating_Data doesn���t use the KDE Framework function for
> reading the translations.

You're right. That's a special case, because it wants to get a specific 
translation, not the one for the currently set locale.
So it parses the .desktop file manually.

This would need an additional patch, yes.

I think most KDE applications do use the KDE functions though.

But as indicated, not all related functions in KDE Libs/Frameworks are patched 
currently (as it wasn't necessary in the past), leading to this bug report in 
the first place.

This caused the problem with the service menus/device actions, and is
(probably) also the cause for the missing plasmoid names/dexcriptions in the
widget explorer (the missing wallpaper descriptions you mentioned should have
the exact same problem, as they are in a similar file structure,
metadata.desktop) 

> From what I can read of the diff of the file, reverting the change would fix
> the problems with both Jovie mentioned above (/usr/share/kde4/apps), KDE
> wallpapers (/share/wallpapers) and theme element descriptions
> (/share/plasma).

Yes. That change is what introduced this bug in 13.2. Reverting it restores 
the situation that was in 13.1 and earlier.

The change was done to fix a problem with autoyast translations apparently, 
but I suppose that should also be possible by just adding the necessary 
folders to the list.


> > This is not only about KDE, but *all* .desktop files included in the
> > distribution (well, most at least, KDE3's are not stripped any more since
> > that change as they are in /opt/kde3/).
> 
> Here you���re only talking about .desktop files for names and descriptions of
> applications, rights?

Yes.

> BTW, how is this handled in *other* desktop environments (GNOME, Xfce,
> LXDE)? Won���t these too need to be patched to properly handle translations of
> names and descriptions of applications in their application menus (and other
> places applications names and descriptions are displayed?)

They *are* patched too, although I haven't checked all. E.g. KDE3 contains the
same patch as KDE4 (and now KF5), glib2 contains this patch to read .desktop
translations from mo files:
https://build.opensuse.org/package/view_file/GNOME:Factory/glib2/glib2-bgo569829-gettext-gkeyfile.patch?expand=1
This should take care of GNOME and its derivatives I think.
Others (IceWM and WindowManager f.i.) run xdg_menu to get the application menu
entries, and this is patched as well:
https://build.opensuse.org/package/view_file/openSUSE:Factory/xdg-menu/xdg-menu-translation-bnc463972.patch?expand=1

> And I���m probably stating the obvious here, but another solution to
> *stripping* translations of applications names and descriptions (which I
> understand is the only thing that needs to be retranslated in openSUSE) and
> patching various parts of KDE to read them from a different place, would  be
> to use the solution KDE itself uses to manage translations of .desktop
> files, i.e., to *(re)insert* translations (made by openSUSE translators)
> into the .desktop files at build time (by the %suse_update_desktop_file rpm
> macro).

The problem I see with this is that it would complicate the build process. In
KDE this is done rather asynchronously.
And all corresponding packages would have to be rebuilt (manually, I suppose),
if one translator makes a change in one particular translation.

I'm not going to discuss this process though, as I don't really have an
insight.
I'm just trying to get the reported issue fixed...