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

[Albert Astals Cid]

El Dimarts, 3 d'abril de 2012, a les 20:05:14, Chusslove Illich va escriure:
> (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"

This means you can't include KLocalizedString in public headers, no? Isn't it 
a bit too much strict?

Albert

> 
> 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.