Comment # 22 on bug 904524 from
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).


You are receiving this mail because: