Bug 829113

Summary: Applications menu and Settinga Manager not fully translated
Product: [openSUSE] openSUSE 12.3 Reporter: Luiz Fernando Ranghetti <elchevive68>
Component: XfceAssignee: E-mail List <bnc-team-xfce>
Status: RESOLVED FIXED QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: coolo, gber, ke, seife
Version: Final   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: screenshot of the bug

Description Luiz Fernando Ranghetti 2013-07-11 18:20:26 UTC
Created attachment 547626 [details]
screenshot of the bug

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/27.0.1453.116 Safari/537.36

Hi,

I've installed openSUSE 12.3 from DVD and choose XFCE as desktop with pt_BR as language.

Although all programs being translated, the application menu and some parts of Setting Manager is not translated.

For example: If you go in Menu -> Settings -> Settings Manager, the title is translated (Configurações) but the modules not (Desktop for example). You open it and the inverse occurs, the title isn't tranlated and the contents are.
The funny part is if you access this setting by right clicking on desktop and choose (Desktop settings), the whole module is translated ;-)

The same occurs for almost every application on the menu.


Reproducible: Always
Comment 1 Guido Berhoerster 2013-07-12 11:55:11 UTC
(In reply to comment #0)
> Although all programs being translated, the application menu and some parts of
> Setting Manager is not translated.
> 
> For example: If you go in Menu -> Settings -> Settings Manager, the title is
> translated (Configurações) but the modules not (Desktop for example). You open
> it and the inverse occurs, the title isn't tranlated and the contents are.
> The funny part is if you access this setting by right clicking on desktop and
> choose (Desktop settings), the whole module is translated ;-)
> 
> The same occurs for almost every application on the menu.

The difference between running a settings dialog embedded in the settings manager and standalone is that in the former case the title and sub-title and their translations are looked up from the corresponding desktop file whereas in the latter case they are hardcoded and translations are looked up via gettext. Now the problem is that the desktop files do not contain localized titles and sub-titles, not sure yet why that is, translations should be added to the desktop files at build time.
Comment 2 Guido Berhoerster 2013-07-12 19:25:50 UTC
So depending on whether brp-trim-desktopfiles is installed in the build environment, brp-70-trim-desktopfiles removes all translations from desktop files. That is, unless %suse_update_desktop_file was called with "-n" on the desktop file. This is apparently based on the assumption that "desktops will use gettext to find them", however this is not the case for Xfce and possibly other non-GNOME/KDE DEs and WMs which simply parse desktop files. Now I could call %suse_update_desktop_file -n on all desktop files in the X11:xfce packages but then all other desktop menu entries would still not be localized.

@Coolo:
Can we change the default behavior of brp-trim-desktopfiles and tolerate a few extra bytes and leave translations in desktop files by default? The above does not only affect xfce4-settings-manager but also the desktop and panel application menus which essentially only contain the English names and comments from the desktop file.
Comment 4 Guido Berhoerster 2013-09-30 08:19:06 UTC
See above.
Comment 6 jc sl 2013-11-30 22:26:42 UTC
This same thing happens with the Spanish translation in openSUSE 13.1. Adding the community repository

   http://download.opensuse.org/repositories/X11:/xfce/openSUSE_13.1/

(the same thing for 12.3) solves most of the translation issues if not all of them (go figure why). However, YaST modules remain untranslated, at least some of them like the Software Management módule (I don't use Xfce and I haven't tested this thoroughly). I can install Xfce in a VM if more info is needed.
Comment 7 jc sl 2013-11-30 23:01:59 UTC
Just to clarify, in my previous comment I meant adding the cited repository and switching the packages to those in that repository.
Comment 8 Guido Berhoerster 2014-10-10 20:06:06 UTC
@coolo:

Can you please have a look at my proposal in comment#2 so that we don't ship yet another release with broken translations?
Comment 9 Stephan Kulow 2014-10-10 22:27:01 UTC
No, if there are translations in desktop files they take preference by KDE and GNOME. But we want the desktop files to be translatable by means of updated PO files.

So find the place where xfce reads desktop files and add a gettext around it. The KDE code is here for reference:
https://build.opensuse.org/package/view_file/openSUSE:13.2/kdelibs4/desktop-translations.diff?expand=1
Comment 10 Guido Berhoerster 2014-10-15 22:23:37 UTC
I've implemented something like this now in libxfce4util, so the xfce_rc_* API falls back to gettext translations for desktop files now. It's not free though, there are additional heap allocations and the gettext calls affecting both speed and memory usage when the desktop file is read (as opposed to glib for example) when the entries are actually accessed due to API constraints in libxfce4util.

I have done quite a bit of testing on 13.2 I'd appreciate it if people could install libxfce4util from the X11:xfce repo and exercise some libxfce4util consumers (the xfce_rc_ API is not only used to parse desktop files but to e.g. by panel plugins to read and write settings and this should not be affected in any way) and test this a bit more with different locales and wrt performance (e.g. opening the application menu on slower computers) and report back here. After that I'll submit to Factory/13.2 and prepare maintenance updates for 12.3 and 13.1.
Comment 11 Guido Berhoerster 2014-10-18 08:27:12 UTC
I've been running this on 13.2 with LANG=de_DE.utf8 for two days now without issues and thus submitted to Factory.
Comment 12 Bernhard Wiedemann 2014-10-18 09:00:08 UTC
This is an autogenerated message for OBS integration:
This bug (829113) was mentioned in
https://build.opensuse.org/request/show/257509 Factory / libxfce4util
Comment 13 Stefan Seyfried 2017-03-01 20:07:02 UTC
wrt comment#12, I'm quite sure this is fixed nowadays.
Comment 14 Swamp Workflow Management 2019-08-05 10:11:44 UTC
This is an autogenerated message for OBS integration:
This bug (829113) was mentioned in
https://build.opensuse.org/request/show/720992 Backports:SLE-12-SP2 / exo+libgarcon+libxfce4ui+libxfce4util+perl-ExtUtils-Depends+perl-ExtUtils-PkgConfig+perl-Glib+thunar+xfce4-dev-tools+xfce4-panel+xfconf
Comment 15 Swamp Workflow Management 2019-10-10 19:12:11 UTC
openSUSE-RU-2019:2305-1: An update that solves one vulnerability and has 10 fixes is now available.

Category: recommended (moderate)
Bug References: 1011518,1047218,1135362,637694,687874,760492,764310,767145,829113,860479,952324
CVE References: CVE-2011-1588
Sources used:
SUSE Package Hub for SUSE Linux Enterprise 12 (src):    exo-0.12.0-2.1, libgarcon-0.6.1-2.1, libxfce4ui-4.12.1-2.1, libxfce4util-4.12.1-2.1, perl-ExtUtils-Depends-0.405-2.1, perl-ExtUtils-PkgConfig-1.160000-2.1, perl-Glib-1.326-2.1, thunar-1.6.14-2.1, xfce4-dev-tools-4.12.0-2.1, xfce4-panel-4.12.2-2.1, xfconf-4.12.1-2.1