Lightweight API for localization of images, icons, etc.

[Chusslove Illich]

> [: David Faure :]
> So using KStandardDirs::locate() is a working solution? Or did you choose
> a solution that makes KStandardDirs::locate() not work? I'm a bit
> confused :-)
>
> (And if locate works, is localizedFilePath() needed?)

Darn my wording, though I don't know how to put it better :)

Yes, this makes KStandardDirs::locate() a working solution, and the method
for manual path wrapping is there only in case KStandardDirs::locate() is
not directly used. Looking around the code in SVN a bit, I saw that at
places e.g. KStandardDirs is used only to locate the top directory of
resources, and then it proceeds with custom code. Only in that case one
would have to manually wrap the final path of interest.

> [: David Faure :]
> A comment about naming: I don't like the addition of the global function
> i18nFilePath [...] Could it be a static method of KLocale instead, for
> proper "namespacing" ?

I should have done so in the first place, it's anyway to be used sparsely.
I'm just wondering about the name itself. In particular now that one would
use KLocale::i18nFilePath(...), which is near to
KGlobal::locale()->localizedFilePath(...). And I'd like to avoid the latter
for general use, because then the caller should for safety first check
KGlobal::hasLocale() (which i18nFilePath does internally).

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080115/01d81785/attachment.sig>