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

Chusslove Illich caslav.ilic at gmx.net
Tue Apr 3 19:05:14 BST 2012


(This is the second and the last thing I want to change in i18n for KF5,
honestly.)

At present (and since forever) it is practically indetermined from which
catalog exactly an i18n() call will fetch the translation. All loaded
catalogs in the process are tried in mostly arbitrary order, depending when
and which library loaded them, and the first one that contains the
translation is used. This leads to situations where a random piece of code
on KDE-Look.org gets for "Sun" the star the translation of "Sun" the short
for Sunday. I think this could pass under the radar so far because KDE was
rather monolithic on the organization level ("go and add context to that
conflicting message"), but it becomes untollerable in the scope of
Frameworks. So the question is how to fix this.

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"

in a "top" include file of the library. This specializes all i18n() calls in
the including sources to look only in foolib catalog and nowhere else. No
other i18n() call in the process will look in foolib catalog (unless
explicitly instructed to). Under the hood there would be no particular
magic, as i18n() calls are just wrappers for
k18n().subs()...subs().toString(), and toString() already has overload that
takes catalog name. Anyone having a better idea? Maybe something more
C++ish.

The other part are .ui files. Since tr() calls generated by uic are actually
calls directly to KDE's tr2i18n(), set via -tr option to uic, I had this in
mind. uic would be updated to recognize -tr func,catalog form as well,
generating calls func("catalog", ...). KDE4_ADD_UI_FILES CMake macro would
get optional catalog name parameter, and pass it on to uic. So, like for C++
sources, the catalog for all .ui files in the library would be stated in
only one place, in its CMakeLists.txt.

The above was all for library code, and for application code the Gettext way
is that non-catalog-specific i18n() calls, i.e. where there was no
#define TRANSLATION_CATALOG before KLocalizedString inclusion, look into the
"main" catalog only. In KDE context, this is the catalog set with KAboutData
or KLocale::setMainCatalog(). So, for normal applications this change would
be fully transparent.

-- 
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/20120403/cede12cc/attachment.sig>


More information about the kde-core-devel mailing list