Lightweight API for localization of images, icons, etc.

[Chusslove Illich]

> [: David Faure :]
> 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...

It's the matter of, so to say, "what is older". I expect the need for
localized resources to pop up rather rarely, and on language-by-language
basis. I imagine that it would then be burdensome for a translator to
coordinate with the programmer rewriting segments of code, just to
accomodate one particular language needing one particular file localized.
With a standalone method, it's just the matter of locating one line of
interest and adding the wrap, with no further modifications. And to someone
refactoring the code later, the intent is made obvious, so as not to mess it
up in the process.

In the very example of KIconTheme in the patch, where I used the wrap in
exactly one place, it would hurt my head severely to examine how to rewrite
it using KStandardDirs instead. Which also means that afterwards I'd have to
pester the maintainer of that code for review and approval :)

>> [: Chusslove Illich :]
>> [...] 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).
>
> [: David Faure :]
> hasLocale is only false in corner cases (hmm, broken installs? unit tests?
> very early during app startup), no?

I personaly would feel less comfortable when adding manual wraps, especially
when I do it in unknown code. I imagine a workflow similar to present for
text localization: translator notices a certain resource that he needs to be
localizable is not, and informs kde-i18n-doc for someone else to fix, or
even fixes it himself. In such a situation it would make me either try to
confirm that the code won't be called too early, or to, more probably,
chicken and check hasLocale() anyway :)

But perhaps it's not appropriate to compare this to current approach for
text i18n fixes, so I've nothing special in favor of the static version.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080115/00a0f51b/attachment.sig>