http://bugzilla.opensuse.org/show_bug.cgi?id=904524
http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c22
--- Comment #22 from Karl Ove Hufthammer
Various KDE applications use the translations stored in .desktop files for *various* purposes, and all these applications must also be patched for all translations to work properly. For an example, see: https://techbase.kde.org/Development/Tutorials/Localization/ i18n_Challenges#Translating_Data (The corresponding openSUSE package is ‘jovi’.) Another example is the names (i.e. descriptions) of wallpapers in KDE.
This should work none-the-less for all translated "Name", "GenericName", and "Comment" entries. They are just taken from openSUSE's desktop_translations.mo (where they get added after they are stripped out of the .desktop file) then, if they are not present in the .desktop file. The patch modifies KDE Frameworks' functions that are used by (KDE) applications to get those translated entries in the first place, so should be transparent to all applications.
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#... doesn’t use the KDE Framework function for reading the translations. The translations are stored in /usr/share/kde4/apps/jovie/kcmkttsd_testmessage.desktop so if this is in the list of folders with desktop files that gets stripped, the stripping code will (still) introduce a bug.
I agree with you though that it's probably not a good idea to unconditionally strip *all* .desktop files in /usr/share/ (see comment#9), that's what caused this bug report in the first place. This was changed here btw: https://build.opensuse.org/request/show/239135 (before that change, only .desktop files in selected directories were stripped)
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).
*if* it’s really the case that openSUSE people really don’t trust the part of > the official KDE translations that happens to be stored in .desktop files instead of .po files, and must supply their own translations
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?
If we would leave out this patch in KDE and even not strip the .desktop files, GNOME applications (and others) would still be untranslated in KDE's application menu.
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?) (In reply to Wolfgang Bauer from comment #21)
All in all I also vote for not stripping *all* .desktop files in /usr/share/, as I already wrote before. If the previous list of directories was not sufficient, this list should be extended, but not be unrestricted...
I agree. 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). Then there would be no patches to maintain, no patches needed for KDE applications that use non-standard ways of fetching translation, and no patches needed for non-KDE applications that supports .desktop files with translations. The only feature that would be missing is that translations of application names/descriptions can’t be updated with updating the application packages. I see this a *very minor* loss of functionality. Two reasons: 1) it’s not currently possible to update translations of *other* parts of an application with rebuilding it, so why should the translation of the names and descriptions need more frequent updates, and 2) in fact the desktop-translations RPM is currently *not* very frequently updated (judging by the changelog, e.g. in Tumbleweed the last (i.e. current) update was done in July, and the one before that 8 months earlier). -- You are receiving this mail because: You are on the CC list for the bug.