RFC: i18n: strict translation call-to-catalog mapping

Chusslove Illich 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__)
      // etc.
      #undef i18n
      #undef i18nc
      // etc.
  // end of file

To point i18n calls to a specific catalog, the inclusion would be like

  #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:

  #include "KLocalizedString"

Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120404/9cf1611a/attachment.sig>

More information about the kde-core-devel mailing list