KLocale plans

David Faure faure at kde.org
Wed Nov 7 12:34:56 UTC 2012


On Sunday 04 November 2012 12:03:18 Chusslove Illich wrote:
> While splitting out public methods dealing with translation from KLocale, I
> got a doubt about localizedFilePath(). For a given file path, it returns the
> localized file path, if available, according to the same language list and
> fallback rules as for strings in PO files. Due to this, initially I thought
> moving it to ki18n. However, this function was also used internally in
> KStandardDirs, so that in a usual KDE program, any file resource could be
> localized without doing anything in the code. Now I see that QStandardDirs
> is replacing KStandardDirs.

Yes (well, it's called QStandardPaths - common mistake, I do it often too).

> It may not seem that this automatic localizability of file resources is that
> much needed, since it is rarely needed, and translator could ask programmer
> to wrap whatever path returned by QStandardDirs with localizedFilePath().

Yes.

> Unfortunatelly, sometimes the programmer also does not handle the path
> directly (e.g. icons). Any idea here?

Well, KIconLoader could call the same method...

> In a perfect world, the text translation library would come earlier in the
> hierarchy, and QStandardDirs would use it internally, just as it was with
> KStandardDirs. Adding this functionality to Qt would make sense, but we will
> then have a mismatch in the language resolution and fallback rules, which
> are quite specific with Gettext. On the other hand, we will have this
> mismatch for text anyway...

I don't think QStandardPaths should have this feature. The way it was done in 
KStandardDirs is... a bit too generic. Who needs 
~/.kde/share/config/l10n/fr/kmailrc ?
Slowing down every file lookup for unnecessary use cases is wasteful and 
confusing.
We should reduce the localizedFilePath feature to the use cases that actually 
need it. Even icon loading is a bit arguable since it's not in the icon theme 
spec. It seems useful though, since the same icon can mean something different 
in different cultures. But there again, this is an edge case, so maybe it 
should be explicitely called by the app.

I wonder if this feature is currently used?
locate /l10n/ | grep usr | grep -v share/locale
-> nothing for me
http://packages.debian.org/fr/wheezy/all/kde-icons-crystal/filelist -> no l10n/
kdesupport/oxygen-icons -> no l10n

I suggest to keep the method in ki18n for now.

KStandardDirs will move to kde4support so it can still call it anyway.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5



More information about the Kde-frameworks-devel mailing list