http://bugzilla.opensuse.org/show_bug.cgi?id=904524 --- Comment #2 from Friedhelm Stappert --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- Component|KDE4 Workspace |Translations Assignee|kde-maintainers@suse.de |ke@suse.com QA Contact|qa-bugs@suse.de |ke@suse.com --- Comment #4 from Wolfgang Bauer --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 --- Comment #6 from Wolfgang Bauer --- (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-translati... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED Component|Translations |KDE4 Workspace Version|13.2 |201503* Product|openSUSE Distribution |openSUSE Factory QA Contact|ke@suse.com |qa-bugs@suse.de --- Comment #8 from Wolfgang Bauer --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugzilla.opensuse.or | |g/show_bug.cgi?id=924000 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 --- Comment #10 from Karl Eichwalder --- (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? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 Hrvoje Senjan changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hrvoje.senjan@gmail.com --- Comment #12 from Hrvoje Senjan --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c15 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(hrvoje.senjan@gma | |il.com) --- Comment #15 from Wolfgang Bauer --- (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... And kservice: https://build.opensuse.org/package/view_file/home:wolfi323:boo932158/kservic... 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... 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... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c17 --- Comment #17 from Wolfgang Bauer --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c19 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(wbauer@tmo.at) | --- Comment #19 from Wolfgang Bauer --- (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/classKSe... 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 -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c21 --- Comment #21 from Wolfgang Bauer --- (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... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c23 --- Comment #23 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-bgo56... 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-m...

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... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c25 --- Comment #25 from Stephan Kulow --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c28 --- Comment #28 from Karl Ove Hufthammer --- (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.) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c31 --- Comment #31 from Wolfgang Bauer --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c33 --- Comment #33 from Wolfgang Bauer --- (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... -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=904524 http://bugzilla.opensuse.org/show_bug.cgi?id=904524#c35 Wolfgang Bauer changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #35 from Wolfgang Bauer --- 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. -- You are receiving this mail because: You are on the CC list for the bug.