Wrapping up about KI18n and UIC

[Stephen Kelly]

Chusslove Illich wrote:

>> [: Stephen Kelly :]
>> If such calls are generated by uic, then that is a bug in Qt (which
>> should have been reported years ago), and should be fixed in Qt, right?
> 
> Maybe, I'm not sure of the conventions of Qt Linguist.

I created a .ui file with a QLabel with an empty text property. I ran uic on 
the file and it generated

    void retranslateUi(QWidget *Form)
    {
        Form->setWindowTitle(QApplication::translate("Form", "Form", 0));
        label->setText(QString());
    }

Unless you have a counter-example, I suggest that uic may have had a bug in 
the past regarding empty strings. That bug was apparently not reported by 
KDE, but it now no longer exists.

>> How would anyone know what to define it to? You said before it is not
>> always the target name. How would someone know whether to make it the
>> target name or not?
> 
> The programmer picks the translation domain name however desired (only it
> must not match any other translation domain anywhere in the world; just
> like an executable name). For a small application named with single
> pure-ASCII word, for example, it is typically chosen as the all-lowercase
> name of the application. The programmer may choose to have any number of
> translation domains, covering different parts of the code, depending on
> its size and organization.

Ok, why would someone using KI18n choose a translation domain which is not 
the lowercased target name? Can't we make that the default, and provide a 
way to override it (if really necessary)?

>> When should semantic markup be used or not? I mean, how would someone
>> using the macro know whether to specify that tr2i18n or tr2xi18n should
>> be used?
> 
> The programmer decides whether to use semantic markup or not, based on
> personal convenience and aesthetics. The default should be no semantic
> markup (tr2i18n), hence the flag type argument to activate it if desired.

I suggest a patch something like this:

diff --git a/tier2/ki18n/KI18nConfig.cmake.in 
b/tier2/ki18n/KI18nConfig.cmake.in
index 8f31c27..83632be 100644
--- a/tier2/ki18n/KI18nConfig.cmake.in
+++ b/tier2/ki18n/KI18nConfig.cmake.in
@@ -5,3 +5,14 @@ find_dependency(KJS "@KF5_VERSION@")
 
 include("${CMAKE_CURRENT_LIST_DIR}/KI18nTargets.cmake")
 
+set(autouic_options
+  -include klocalizedstring.h
+  -tr tr2$<$<NOT:$<BOOL:$<TARGET_PROPERTY:NO_KUIT_SEMANTIC>>:x>i18n
+)
+set_property(TARGET KF5::KI18n APPEND PROPERTY INTERFACE_AUTOUIC_OPTIONS 
"${autouic_options}")
+set(domain_logic
+  $<$<BOOL:$<TARGET_PROPERTY:TRANSLATION_DOMAIN>>:
$<TARGET_PROPERTY:TRANSLATION_DOMAIN>>$<NOT:$<BOOL:
$<TARGET_PROPERTY:TRANSLATION_DOMAIN>>:$<TOLOWER:$<MAKE_C_IDENTIFIER:
$<TARGET_PROPERTY:NAME>>>>
+)
+set_property(TARGET KF5::KI18n APPEND PROPERTY 
INTERFACE_COMPILE_DEFINITIONS "-DTRANSLATION_DOMAIN=${domain_logic}")
+unset(autouic_options)
+unset(domain_logic)

 
That way, the uic options are a 'usage requirement'. See my recent blog post 
for more background on usage requirements:

 http://www.kdab.com/modern-cmake-with-qt-and-boost/

Anyone using AUTOUIC and linking transitively with KF5::KI18n will 
automatically invoke uic with the -include and with the appropriate -tr 
function. The downstream can choose to use tr2i18n by setting the 
NO_KUIT_SEMANTIC target property.

 set_property(TARGET gwenview PROPERTY NO_KUIT_SEMANTIC TRUE)

You can wrap that in a macro if you wish. The default is to use KUIT.

The translation domain is the target name, transformed into a C identifier 
and lowercased, by default. The user can override that by setting the 

 set_property(TARGET konsole PROPERTY TRANSLATION_DOMAIN kdekonsole)

You can wrap that in a macro if you wish. 

This depends on Qt 5.3 and CMake master plus some trivial new generator 
expressions. Aside from bikeshedding names of things and defaults, can you 
see any problem with this?

Thanks,

Steve.