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.