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

[Chusslove Illich]

>> [: 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 (Часлав Илић)
-------------- 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>