Bug 904524

openSUSE-RU-2015:0492-1: An update that solves one vulnerability and has three fixes is now available.

Category: recommended (moderate)
Bug References: 904524,911205,912121,912317
CVE References: CVE-2015-0295
Sources used:
openSUSE 13.2 (src):    attica-qt5-5.7.0-12.3, baloo5-5.6.1-12.16, bluedevil5-5.2.1-2.4, breeze-5.2.1-12.3, breeze4-style-5.2.1-12.1, extra-cmake-modules-1.7.0-12.1, fcitx-qt5-0.1.2-2.5.3, frameworkintegration-5.7.0-12.1, kactivities5-5.7.0-12.1, kapidox-5.7.0-12.1, karchive-5.7.0-12.3, kauth-5.7.0-12.3, kbookmarks-5.7.0-12.1, kcm-touchpad5-5.2.1~git20150225-2.19, kcm_sddm-5.2.1-2.30, kcmutils-5.7.0-12.1, kcodecs-5.7.0-12.3, kcompletion-5.7.0-12.3, kconfig-5.7.0-12.3, kconfigwidgets-5.7.0-12.3, kcoreaddons-5.7.0-12.3, kcrash-5.7.0-12.3, kdbusaddons-5.7.0-12.3, kde-cli-tools5-5.2.1-12.2, kde-gtk-config5-5.2.1-2.4, kdeclarative-5.7.0-12.1, kded-5.7.0-12.1, kdelibs4support-5.7.0-12.7, kdesignerplugin-5.7.0-12.4, kdesu-5.7.0-12.3, kdewebkit-5.7.0-12.1, kdnssd-framework-5.7.0-12.3, kdoctools-5.7.0-12.8, kemoticons-5.7.0-12.3, kfilemetadata5-5.6.1-12.3, kglobalaccel-5.7.0-12.3, kguiaddons-5.7.0-12.3, khotkeys5-5.2.1-17.10, khtml-5.7.0-12.1, ki18n-5.7.0-12.5, kiconthemes-5.7.0-12.2, kidletime-5.7.0-12.5, kimageformats-5.7.0-12.3, kinfocenter5-5.2.1-12.2, kinit-5.7.0-12.1, kio-5.7.0-12.3, kio-extras5-5.2.1-13.5, kitemmodels-5.7.0-12.3, kitemviews-5.7.0-12.3, kjobwidgets-5.7.0-12.3, kjs-5.7.0-12.3, kjsembed-5.7.0-12.5, kmediaplayer-5.7.0-12.1, kmenuedit5-5.2.1-12.4, knewstuff-5.7.0-12.1, knotifications-5.7.0-12.2, knotifyconfig-5.7.0-12.1, kpackage-5.7.0-6.3, kparts-5.7.0-12.1, kplotting-5.7.0-12.3, kpty-5.7.0-12.3, kross-5.7.0-12.3, krunner-5.7.0-12.1, kscreen5-5.2.1-2.2, kservice-5.7.0-12.2, ksshaskpass5-5.2.1-2.2, ksysguard5-5.2.1-12.8, ktexteditor-5.7.0-12.1, ktextwidgets-5.7.0-12.1, kunitconversion-5.7.0-12.3, kwallet-5.7.0-12.2, kwayland-5.2.1-12.3, kwidgetsaddons-5.7.0-12.3, kwin5-5.2.1-12.5, kwindowsystem-5.7.0-13.5, kwrited5-5.2.1-12.2, kxmlgui-5.7.0-12.2, libKF5ModemManagerQt-5.2.1-12.3, libKF5NetworkManagerQt-5.7.0-12.2, libbluedevil5-5.2.1-2.3, libkdecoration2-5.2.1-2.3, libkscreen2-5.2.1-12.3, libksysguard5-5.2.1-12.7, libqt5-creator-3.3.1-9.1, libqt5-qtbase-5.4.1-16.1, libqt5-qtconnectivity-5.4.1-2.1, libqt5-qtct-0.8-2.1, libqt5-qtdeclarative-5.4.1-5.1, libqt5-qtdoc-5.4.1-5.1, libqt5-qtgraphicaleffects-5.4.1-4.1, libqt5-qtimageformats-5.4.1-4.1, libqt5-qtlocation-5.4.1-4.1, libqt5-qtmultimedia-5.4.1-4.1, libqt5-qtquick1-5.4.1-4.1, libqt5-qtquickcontrols-5.4.1-8.1, libqt5-qtscript-5.4.1-4.1, libqt5-qtsensors-5.4.1-4.1, libqt5-qtserialport-5.4.1-4.1, libqt5-qtsvg-5.4.1-4.1, libqt5-qttools-5.4.1-4.1, libqt5-qttranslations-5.4.1-4.1, libqt5-qtwayland-5.4.1-4.1, libqt5-qtwebchannel-5.4.1-2.1, libqt5-qtwebengine-5.4.1-2.1, libqt5-qtwebkit-5.4.1-5.1, libqt5-qtwebkit-examples-5.4.1-4.1, libqt5-qtwebsockets-5.4.1-4.1, libqt5-qtx11extras-5.4.1-4.1, libqt5-qtxmlpatterns-5.4.1-4.1, milou5-5.2.1-12.4, oxygen5-5.2.1-12.1, plasma-framework-5.7.0-14.3, plasma-nm5-5.2.1-14.1, plasma5-addons-5.2.1-12.1, plasma5-desktop-5.2.1-16.1, plasma5-openSUSE-13.2-8.1, plasma5-session-5.2.1-4.1, plasma5-workspace-5.2.1-20.1, plasma5-workspace-wallpapers-5.2.1-12.1, polkit-default-privs-13.2-7.9.1, polkit-kde-agent-5-5.2.1-2.4.1, powerdevil5-5.2.1-8.1, python-qt5-5.3.1-2.5.1, python3-qt5-5.3.1-2.5.1, rpmlint-mini-1.5-8.4.1, solid-5.7.0-12.1, sonnet-5.7.0-12.3, systemsettings5-5.2.1-12.1, threadweaver-5.7.0-12.1

As far as I can see, all entries are translated now -- except those related to k3b; e.g. "Create Audio CD with k3b", "Copy with k3b" etc.

(In reply to Friedhelm Stappert from comment #2)
> As far as I can see, all entries are translated now -- except those related
> to k3b; e.g. "Create Audio CD with k3b", "Copy with k3b" etc.

Install k3b from KDE:Extra or Packman and they should be translated...

Oh, and lets better assign this to the component "Translations", I'd say.

This never was a bug in the "KDE4 Workspace".

The problem was/is that the translations got removed from all of KDE's .desktop files for the 13.2 release, but those translations were not provided anywhere else.

The KDE updates were not stripped, so the translations are now available.

Something like that should better not happen again for the next release.

If I got it right everything is translated and shipped in some package, but those package or packages are not installed if the user selects the wanted language.

Looks like a pattern issue or something similar.  I fear I cannot do that much about this.

(In reply to Karl Eichwalder from comment #5)
> If I got it right everything is translated and shipped in some package, but
> those package or packages are not installed if the user selects the wanted
> language.

Hm. I'm pretty sure that the reporter and I had desktop-translations (which should contain those translations IIUIC) installed when noticing this after upgrading to 13.2.

See also https://forums.opensuse.org/showthread.php/502326-13-2-KDE-Missing-translations-in-context-menus-and-device-actions?p=2674209#post2674209

(In reply to Wolfgang Bauer from comment #3)
> (In reply to Friedhelm Stappert from comment #2)
> > As far as I can see, all entries are translated now -- except those related
> > to k3b; e.g. "Create Audio CD with k3b", "Copy with k3b" etc.
> 
> Install k3b from KDE:Extra or Packman and they should be translated...

Yep; the Packman version includes the translations. Thanks!

(In reply to Friedhelm Stappert from comment #7)
> Yep; the Packman version includes the translations. Thanks!

Well, I guess we could/should release K3B 2.0.3 as bugfix update for 13.2. This would also "fix" the translation issue there.
But I will create a separate bug report for this.

Btw, the general problem does also (still) exist in current Tumbleweed as well, with desktop-translations installed. (I don't remember installing them manually, so I think the patterns are ok regarding this)

I just looked at desktop_translations.mo (from desktop-translations) with a hex editor, and the translations indeed seem to be in there.

So maybe the patches for KDE to read those translations do not work any more?
This might actually be a (openSUSE) KDE bug after all...
I will investigate this further in the next days when I find the time.

What I found out so far:
The kdelibs4 patches that read the translated entries from desktop-translations haven't changed since 13.1 (where the problem didn't exist), and are working fine.
But, they do not touch the code that reads the sevice menus and device actions (i.e. "[Desktop Action xxx]" sections in the .desktop files), those translations never were taken from desktop-translations, only from the .desktop files themselves.

In 13.1, those translations were part of the corresponding .desktop files, and _not_ stripped and moved to desktop-translations. Now (13.2 and Tumbleweed) they are, and the service menus and device actions are therefore untranslated.

So for me the question is:
Have those translations for "desktop actions" been split out on purpose or by mistake?
If it's done on purpose, the KDE patches have to be modified.
If not, the thing that removes those translations (some buggy script maybe?) should be corrected.

Another question that I have would be why this (removing the translations from the .desktop files) is not done for updates. This defeats the purpose of having the translations in a separate package/file completely IMHO because the translations from desktop-translations are not used at all any more for most things if there are full KDE (and/or GNOME) updates.

Btw, I think these KDE patches also have to be ported to KF5 and added there, in particular if Plasma5 is to become the default desktop.
Although this bug report has been mentioned in the Plasma5 update (see comment#1), I don't think this is the case yet.

(In reply to Wolfgang Bauer from comment #9)
> What I found out so far:
> The kdelibs4 patches that read the translated entries from
> desktop-translations haven't changed since 13.1 (where the problem didn't
> exist), and are working fine.
> But, they do not touch the code that reads the sevice menus and device
> actions (i.e. "[Desktop Action xxx]" sections in the .desktop files), those
> translations never were taken from desktop-translations, only from the
> .desktop files themselves.
> 
> In 13.1, those translations were part of the corresponding .desktop files,
> and _not_ stripped and moved to desktop-translations. Now (13.2 and
> Tumbleweed) they are, and the service menus and device actions are therefore
> untranslated.
> 
> So for me the question is:
> Have those translations for "desktop actions" been split out on purpose or
> by mistake?
> If it's done on purpose, the KDE patches have to be modified.
> If not, the thing that removes those translations (some buggy script maybe?)
> should be corrected.
> 
> Another question that I have would be why this (removing the translations
> from the .desktop files) is not done for updates. This defeats the purpose
> of having the translations in a separate package/file completely IMHO
> because the translations from desktop-translations are not used at all any
> more for most things if there are full KDE (and/or GNOME) updates.
> 
> Btw, I think these KDE patches also have to be ported to KF5 and added
> there, in particular if Plasma5 is to become the default desktop.
> Although this bug report has been mentioned in the Plasma5 update (see
> comment#1), I don't think this is the case yet.

Thanks for detailed debugging!  coolo, did we or you change something related before 13.2?

(In reply to Karl Eichwalder from comment #10)
> Thanks for detailed debugging!  coolo, did we or you change something
> related before 13.2?

I investigated a bit more today, and found the change.
It's in brp-trim-desktop.sh (package "update-desktop-files").

In 13.1 this has:
find /$RPM_BUILD_ROOT/opt/kde3/share/applications/kde/ \
  /$RPM_BUILD_ROOT/opt/kde3/share/applnk/ \
  /$RPM_BUILD_ROOT/usr/share/xsessions/ \
  /$RPM_BUILD_ROOT/usr/share/applications/ \
  /$RPM_BUILD_ROOT/usr/share/mimelnk/ \
  /$RPM_BUILD_ROOT/usr/share/gnome/apps/ \
  /$RPM_BUILD_ROOT/etc/xdg/autostart/ -name *.desktop -o -name .directory 2>/dev/null | while read FILE; do

In 13.2 and Factory it's just:
find /$RPM_BUILD_ROOT/usr/share /$RPM_BUILD_ROOT/etc/xdg/autostart/ \
    -type f \( -name '*.desktop' -o -name .directory \) 2>/dev/null | while read -r FILE; do

So in 13.1 only specific directories were searched for the .desktop files to trim, whereas in 13.2 and Factory _all_ subdirectories of /usr/share/ are searched, which includes /usr/share/kde4/services/ServiceMenus/ e.g.

(I have no idea why that script is not called at all in the update repo or in the OBS KDE repos though...)

So the question still stands whether this is wanted or not.
IOW, should brp-trim-desktop.sh be "fixed", or should the kdelibs4 patch be adapted.

The patch is almost 100% copy for kconfig, except for:
KGlobal::locale()->translateRaw(po_lookup_key.toUtf8().data(), NULL, &po_value);

1) the function is dead in KF5
2) kconfig wouldn't be able to depend on ki18n anyway (both are tier 1 Frameworks)

I don't know is there something similar in Qt itself we could use.

Could anyone explain *why* the strings are removed from the .desktop files (and moved into a different package, and the software modified to read the strings from this package)? Why strip the files from the .desktop files at all? Other distros do not do this, and if the translations are not stripped, everything works fine.

to:
 1. minimize the installed the languages to the ones users want
 2. minimize the parsing time of said desktop files
 3. be able to fix the translations without updating application packages
 4. be able to add other translations without updating all application packages
 5. to give openSUSE translators one compendium to look through for consistency

Enough reasons?

(In reply to Hrvoje Senjan from comment #12)
> The patch is almost 100% copy for kconfig, except for:
> KGlobal::locale()->translateRaw(po_lookup_key.toUtf8().data(), NULL,
> &po_value);
> 
> 1) the function is dead in KF5
> 2) kconfig wouldn't be able to depend on ki18n anyway (both are tier 1
> Frameworks)
> 
> I don't know is there something similar in Qt itself we could use.

I played with this in the last days.
Actually the KDE4 patch worked fine when replacing that by a call to QObject::tr().
But I didn't succeed in loading the translation file with Qt5 (the KDE4 patch uses KLocale for that too).

Anyway, I was able to port it by just using gettext (dgettext() to be exact).

Here's the kconfig part of my patch:
https://build.opensuse.org/package/view_file/home:wolfi323:boo932158/kconfig/kconfig-desktop-translations.patch?expand=1

And kservice:
https://build.opensuse.org/package/view_file/home:wolfi323:boo932158/kservice/kservice-desktop-translations.patch?expand=1
Works fine here in my tests (with german locale).

Should I submit it?
Comments are welcome of course.

One thing I'm not completely sure about, though:
The KDE4 patch also loads the translation catalogs "kde4-openSUSE" and "kde4-SLE" in addition to "desktop_translations", see https://build.opensuse.org/package/view_file/KDE:Distro:Factory/kdelibs4/add-suse-translations.diff?expand=1

Those don't exist in Tumbleweed AFAICT, so I suppose using them is not necessary. Or is there some replacement?
OTOH, I don't think they ever contained .desktop file translations at all, "kde4-openSUSE" doesn't on 13.2 at least...

(In reply to Wolfgang Bauer from comment #15)
> (In reply to Hrvoje Senjan from comment #12)
> > The patch is almost 100% copy for kconfig, except for:
> > KGlobal::locale()->translateRaw(po_lookup_key.toUtf8().data(), NULL,
> > &po_value);
> > 
> > 1) the function is dead in KF5
> > 2) kconfig wouldn't be able to depend on ki18n anyway (both are tier 1
> > Frameworks)
> > 
> > I don't know is there something similar in Qt itself we could use.
> 
> I played with this in the last days.
> Actually the KDE4 patch worked fine when replacing that by a call to
> QObject::tr().

Note that this would only fix part of the problem with translations being stripped from .desktop. 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.

I work as a translator for KDE (and openSUSE), and has noticed that KDE is moving to using .desktop files for storing translations for many things (i.e. stuff that isn’t source code). (Other formats could be used, and XML are also used, but we have software for easily parsing .desktop files, generating .po files and reinserting the translations in the .po files, so it’s a simple solution.)

It seems to me that stripping *all* translations (i.e. not only names and descriptions of applications) from .desktop files and patching all software that consumes .desktop files creates more problems than it solves. IMHO, a better solution (*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 – something I find rather strange, BTW), would be to instead overwrite the translations in the .desktop files with the openSUSE translations (iff they exist).

> One thing I'm not completely sure about, though:
> The KDE4 patch also loads the translation catalogs "kde4-openSUSE" and
> "kde4-SLE" in addition to "desktop_translations", see
> https://build.opensuse.org/package/view_file/KDE:Distro:Factory/kdelibs4/add-
> suse-translations.diff?expand=1
> 
> Those don't exist in Tumbleweed AFAICT, so I suppose using them is not
> necessary.

At least kde4-openSUSE exists as a .po(t) (translation) file in trunk and the openSUSE-13_2-Branch. (There hasn’t been created a translation file for Leap yet.)

> OTOH, I don't think they ever contained .desktop file translations at all,
> "kde4-openSUSE" doesn't on 13.2 at least...

Indeed.

(In reply to Karl Ove Hufthammer from comment #16)
> Note that this would only fix part of the problem with translations being
> stripped from .desktop.

Yes. It's a port of KDE4's (and KDE3's) patch that reads those translated entries from desktop_translations.mo if they are not found in the .desktop file.
This brings KF5 in line with KDE4 regarding this.

It doesn't fix anything (yet) in regards to the originally reported problem here.

> 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.

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)

> *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/).
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.

(In reply to Wolfgang Bauer from comment #15)
> (In reply to Hrvoje Senjan from comment #12)
> > The patch is almost 100% copy for kconfig, except for:
> > KGlobal::locale()->translateRaw(po_lookup_key.toUtf8().data(), NULL,
> > &po_value);
> > 
> > 1) the function is dead in KF5
> > 2) kconfig wouldn't be able to depend on ki18n anyway (both are tier 1
> > Frameworks)
> > 
> > I don't know is there something similar in Qt itself we could use.
> 
> I played with this in the last days.
> Actually the KDE4 patch worked fine when replacing that by a call to
> QObject::tr().
> But I didn't succeed in loading the translation file with Qt5 (the KDE4
> patch uses KLocale for that too).
> 
> Anyway, I was able to port it by just using gettext (dgettext() to be exact).
> 
> Here's the kconfig part of my patch:
> https://build.opensuse.org/package/view_file/home:wolfi323:boo932158/kconfig/
> kconfig-desktop-translations.patch?expand=1
> 
> And kservice:
> https://build.opensuse.org/package/view_file/home:wolfi323:boo932158/
> kservice/kservice-desktop-translations.patch?expand=1
> Works fine here in my tests (with german locale).
> 
> Should I submit it?
> Comments are welcome of course.

Please do; many thanks for looking deeper into this.

Regarding ServiceMenus, etc. do i understand correctly that the issue is now due  to translations not injected back into desktop-translations.mo?

(In reply to Hrvoje Senjan from comment #18)
> Please do; many thanks for looking deeper into this.

OK, I will do later today.

> Regarding ServiceMenus, etc. do i understand correctly that the issue is now
> due  to translations not injected back into desktop-translations.mo?

No. That part is ok. The translations are in desktop_translations.mo.

But the KDE patch only reads the normal "Name", "GenericName", and "Comment" fields from desktop_translations (i.e. it patches the functions KDesktopFile::readName(), ::readGenericName(), and ::readComment()).

The ServiceMenus are so-called "Device Actions" (see also comment#9), there can be more than one per .desktop file. See also http://api.kde.org/frameworks-api/frameworks5-apidocs/kservice/html/classKServiceAction.html

In detail, those .desktop files (located in /usr/share/kde4/services/ServiceMenus/ and /usr/share/kservices5/ServiceMenus/, the device actions are in /usr/share/(kde4/)solid/actions/) look like this:
[Desktop Entry]
Type=Service
Actions=CreateK3bAudioProject;
...
[Desktop Action CreateK3bAudioProject]
Exec=k3b --audiocd %F
Name=Create Audio CD with K3b
Name[ar]=...

There are separate functions in libkdecore (now kservice) for getting those actions, and they are not patched and only consider the translations in the .desktop file... (those .desktop files were not stripped anyway until the change mentioned in my previous comment)
I.e. KServicePrivate::parseActions() calls KConfigGroup::readEntry("Name") and so on, this would need to be changed.

I see three possible ways to fix that:
- revert the change in brp-trim-desktop.sh (package update-desktop-files) to again not unconditionally strip all .desktop files in the whole /usr/share/ hierarchy, but only in selected folders
- make brp-trim-desktop.sh a bit smarter in parsing the files, and leave "Device Actions" in
- extend the KDE patch to read those translations from desktop_translations.mo too

I would vote for restoring <= 13.1 behaviour. Even with additional patch for kservice, we would need to patch e.g. kio and whatnot for X-KDE-Submenu names (at least i don't see a global API for that)

(In reply to Hrvoje Senjan from comment #20)
> I would vote for restoring <= 13.1 behaviour. Even with additional patch for
> kservice, we would need to patch e.g. kio and whatnot for X-KDE-Submenu
> names (at least i don't see a global API for that)

Those should not be a problem, the script only strips out lines that start with Name[, GenericName[, and Comment[:

	grep -v -E '^Name\[|^GenericName\[|^Comment\[' $FILE > ${FILE}_ 

I noticed another problem though meanwhile:
The plasmoid names/descriptions in the widget explorer are still untranslated.
In KDE4 this only affects a few ones, namely those that have a metadata.desktop in /usr/share/kde4/apps/plasma/plasmoids/, in Plasma5/TW all are affected AFAICS (probably because all have a metadata.desktop in /usr/share/plasma/plasmoids/ now).

This might need an additional patch to KPluginInfo.
But this problem might even be related to the fact that all those .desktop files are named "metadata.desktop" (the filename is used in the msgid for looking up the translation to make sure it's unique).

And there might be other side-effects as well, especially for non-KDE applications that might have a .desktop file somewhere in /usr/share/ and not expect having to read the translations from some mo file.

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...

Some minor comments (to various comments):

(In reply to Wolfgang Bauer from comment #17)
> > 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#Translating_Data 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).

(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...

There's been no movement again here since my last comment, so I'd again like to ask that we fix this for the next release (Leap 42.1 now).

As we (Hrvoje, Kai Ove, and me) seem to agree that reverting https://build.opensuse.org/request/show/239135 would be the best thing to do:
@Stephan Kulow:
I'm not sure what the problem with autoyast was.
What exactly did you try to solve there?
Can't we solve it differently, by adding some directories to the list?

For me this is actually a ship stopper I have to say.

It's sad that 13.2 was released with this problem, but Tumbleweed still has it, and Leap should have it too?

I suppose more people are using KDE than autoyast, especially since that's the default desktop on a default installation in openSUSE...

autoyast was about /usr/share/autoinstall - and at that time it seemed like a good idea just to take all *.desktop files. That apps name their files .desktop if they are not is a bug in them IMO, but be it as it is.

I created SR#340702 to go back to a list of directories. That official openSUSE updates aren't stripped is a problem I didn't think about before.

That KDE repos aren't stripped is on purpose, so that new upstream releases have proper upstream releases. The minimizing effect can only happen within the openSUSE context.

This is an autogenerated message for OBS integration:
This bug (904524) was mentioned in
https://build.opensuse.org/request/show/340702 Factory / update-desktop-files
https://build.opensuse.org/request/show/340703 Leap:42.1 / update-desktop-files

it should be noted that a valid fix for your problem is to mark those desktop files we *know* are better translated upstream (or not at all).

you do that by calls to suse_update_desktop_file with -n

%kde_post_install from macros.kde4 does that for some files - and possibly it should do for more.

(In reply to Stephan Kulow from comment #27)
> it should be noted that a valid fix for your problem is to mark those
> desktop files we *know* are better translated upstream (or not at all).
> 
> you do that by calls to suse_update_desktop_file with -n
> 
> %kde_post_install from macros.kde4 does that for some files - and possibly
> it should do for more.

At least the following packages should do this:

breeze5-wallpapers
plasma5-workspace-wallpapers
kdeartwork4-wallpapers
kdeartwork4-wallpapers-weather
kdebase4-wallpapers
kdebase4-wallpaper-default

(I tried figuring out how to report bugs for these packages, but I couldn’t find the ‘little beetle icon’ that https://en.opensuse.org/openSUSE:Submitting_bug_reports mentions.)

With the update of the macro, my part is done. It's up to the KDE packagers if they want to go fully ballistic as mentioned in #28 or close as FIXED

OK. I’ve filed #955475 for the wallpaper translation issue.

First of all, thank you for the fix!

But, I just don't understand why /usr/share/wallpapers/ has now been added to the list of directories to be stripped, it wasn't in there before https://build.opensuse.org/request/show/239135...

I suppose we should add those %suse_update_desktop_file calls for each and every wallpaper then.
Although I think having /usr/share/wallpapers/ in the directory list doesn't make any sense at all if we exclude all of the .desktop files from there manually anyway, no?

Unfortunately, %kde_post_install from macros.kde4 is not used in the KF5/Plasma5 packages for obvious reasons, and at the moment there's no similar macro in use by those packages.

(In reply to Wolfgang Bauer from comment #31)
> But, I just don't understand why /usr/share/wallpapers/ has now been added
> to the list of directories to be stripped, it wasn't in there before
> https://build.opensuse.org/request/show/239135...

I can’t speak for Stephan Kulow, but note that there are wallpapers in /usr/share/wallpapers/ that don’t come from a software distribution like KDE or GNOME (which provide proper translations along with the wallpapers), e.g.:

wallpaper-branding-openSUSE
desktop-data-openSUSE-extra

(In reply to Karl Ove Hufthammer from comment #32)
> (In reply to Wolfgang Bauer from comment #31)
> > But, I just don't understand why /usr/share/wallpapers/ has now been added
> > to the list of directories to be stripped, it wasn't in there before
> > https://build.opensuse.org/request/show/239135...
> 
> I can’t speak for Stephan Kulow, but note that there are wallpapers in
> /usr/share/wallpapers/ that don’t come from a software distribution like KDE
> or GNOME (which provide proper translations along with the wallpapers), e.g.:
> 
> wallpaper-branding-openSUSE
> desktop-data-openSUSE-extra

Yes, but as those do not contain any translations in their .desktop files at all, it also doesn't make sense to strip them.

Or are those translations in desktop-translations?
Then it probably would be a good idea to investigate why KDE doesn't read the translations for the wallpapers from there and try to fix that if possible...

(In reply to Wolfgang Bauer from comment #33)
> Or are those translations in desktop-translations?

To answer myself here: yes, they are.
But they would probably be in there also if /usr/share/wallpapers/ is not stripped IIUIC. So not really a reason to have it in the list, is it?

Btw, I just noticed that also some other wallpapers are not translated here (13.2/KDE4) even though the translations are available in the .desktop files themselves.
It seems that KDE (4 and 5) just doesn't support to have an xxx.png.desktop file for a wallpaper xxx.png, it apparently wants a metadata.desktop.

As a side-note: I just tried in GNOME, and that doesn't show a name at all for wallpapers...

Ok, let's finally close this.
The bug as reported has been fixed (in time for Leap 42.1).

For the wallpapers we have the separate bug report anyway.