>> [: 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
templates.
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:
#ifndef KLOCALIZEDSTRING_H
#define KLOCALIZEDSTRING_H
// All normal stuff.
#endif
// end of include guard
#ifdef TRANSLATION_CATALOG
#define i18n(...) i18nd(TRANSLATION_CATALOG, __VA_ARGS__)
#define i18nc(...) i18ndc(TRANSLATION_CATALOG, __VA_ARGS__)
// etc.
#else
#undef i18n
#undef i18nc
// etc.
#endif
// end of file
To point i18n calls to a specific catalog, the inclusion would be like
before:
#define TRANSLATION_CATALOG "foolib"
#include "KLocalizedString"
but if this was a public header, to unpollute the client code at the end of
file inclusion would be repeated like this:
#undef TRANSLATION_CATALOG
#include "KLocalizedString"
--
Chusslove Illich (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.
