Lightweight API for localization of images, icons, etc.

David Faure faure at
Tue Jan 15 12:31:14 GMT 2008

On Tuesday 15 January 2008, Chusslove Illich wrote:
> > [: 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.

OK, but the real question is: are we sure that this code couldn't use KStandardDirs instead? :-)
I am not convinced about adding redundant API just because application code doesn't do things right, you see...

> 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).

hasLocale is only false in corner cases (hmm, broken installs? unit tests? very early during app startup), no?

David Faure, faure at, sponsored by Trolltech to work on KDE,
Konqueror (, and KOffice (

More information about the kde-core-devel mailing list