[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: KTrader::query() with non-Latin1 constraints
From:       David Faure <faure () kde ! org>
Date:       2006-01-06 13:14:48
Message-ID: 200601061414.48332.faure () kde ! org
[Download RAW message or body]

On Friday 06 January 2006 13:47, Gary Cramblitt wrote:
> The list of translated plugin names (from the .desktop files) is displayed to 
> user.  When user picks one, the DesktopEntryName is stored in their 
> configuration and that name is used from then on.  Of course, I can keep both 
> the translated name and DesktopEntryNames in a QMap so that when user picks a 
> translated name, I can know the DesktopEntryName, but that's more code I 
> didn't expect to need.  

This would be much more robust. With the current situation, if a translator
fixes a translation for 3.5.1, or translates a string that wasn't transalted before,
the user configuration will break.
Storing translated strings as identifiers is very fragile.

> I  (wrongly) assumed KTrader had that information
It does, but it's too variable to be useful.

> If this *is* a limitation of KTrader and too involved to fix, I'd suggest a 
> note in the API docs warning about it.
KService::serviceByName has such a warning btw.

> I can fix the problem in my code fairly easily, but unfortunately too late for 
> KDE 3.5.  What led me astray is my code works fine for iso-8859-1 languages, 
> like German and Italian, but not for languages like Czech, which is 
> iso-8859-2.
... but breaks anyway if such translations are modified.

I strongly suggest to use the desktopEntryName as the identifier.

-- 
David Faure, faure@kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]