RFC: i18n: strict translation call-to-catalog mapping
caslav.ilic at gmx.net
Wed Apr 4 19:38:41 BST 2012
>> [: Chusslove Illich :]
>> For C++ code, I couldn't think of a better solution than that advised for
>> plain Gettext, and e.g. as formalized in Glib. It would amount to having:
>> #define TRANSLATION_CATALOG "foolib"
>> #include "KLocalizedString"
> [: Albert Astals Cid :]
> This means you can't include KLocalizedString in public headers, no? Isn't
> it a bit too much strict?
I thought forward declarations would suffice, assuming KLocalizedString to
be used as function parameters at places. But now when I examined some
amount of public headers, it is also used as empty default value and even
i18n'd default value for such parameters. While these could be thrown out,
if a bit uglish (passing pointer default to null instead of reference), I've
also found one use of i18n call inside a template. I completely forgot about
So, how about this. With strict mapping, there would also be i18nd*() series
of calls which take as first argument the catalog name (like d*gettext()
calls); I didn't mention them earlier because they weren't important for the
proposal. But they would now be implicitly used as follows.
klocalizedstring.h would look like this:
// All normal stuff.
// end of include guard
#define i18n(...) i18nd(TRANSLATION_CATALOG, __VA_ARGS__)
#define i18nc(...) i18ndc(TRANSLATION_CATALOG, __VA_ARGS__)
// end of file
To point i18n calls to a specific catalog, the inclusion would be like
#define TRANSLATION_CATALOG "foolib"
but if this was a public header, to unpollute the client code at the end of
file inclusion would be repeated like this:
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel