(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 (Часлав Илић)
signature.asc
Description: This is a digitally signed message part.