Lightweight API for localization of images, icons, etc.
faure at kde.org
Tue Jan 15 12:04:04 GMT 2008
On Tuesday 15 January 2008, Chusslove Illich wrote:
> I thought it would be nice to have a simple system (in 4.1) for localizing
> general external resources in KDE apps -- splash screens, icons, sounds,
> whatever is provided as a non-text file.
> The solution would proceed as follows. For a resource file installed by the
> application at $SOMEDIR/foo.bar, a localized counterpart (for any language
> that cares to supply one), would be installed in $SOMEDIR/l10n/LL/foo.bar,
> where LL is the language code. If the app scoops the original foo.bar
> through one of standard mechanisms, e.g. KStandardDirs::locate(), these
> localized alternatives would automatically be returned when existing and
> appropriate. If the application assembles the path itself, then a wrap of
> i18nFilePath(finalPath) would do the same lookup (these manual wraps would
> be added only on explicit translator request).
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?)
> I've opted for the $SOMEDIR/l10n/LL/foo.bar approach, instead of e.g.
> $SOMEDIR/LL.foo.bar or $SOMEDIR/LL/foo.bar, because it will produce the
> least clutter in directories, both packed and installed. It makes it easy
> for a maintainer of an extragear app to collect any such localized resources
> for his app from l10n-kde4/LL/data language directories, and add simple
> INSTALL(DIRECTORY l10n ...) rules in his CMakeLists.txt files which install
> the original resources (even if that).
> The attached patch implements the i18nFilePath() and it's underlying
> KLocale::localizedFilePath() worker. It also adds i18nFilePath() at only two
> places in KStandardDirs and one in KIconTheme, by which all the well-behaved
> resource lookups and icons become localizable without further intervention.
A comment about naming: I don't like the addition of the global function i18nFilePath,
after we cleaned up the KDE API of global functions as much as possible (e.g. locate() and locateLocal()).
Could it be a static method of KLocale instead, for proper "namespacing" ?
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel