Finalized proposal for i18n in KF5, second iteration

[Oswald Buddenhagen]

On Mon, May 20, 2013 at 12:08:36AM +0200, Chusslove Illich wrote:
> > [: Oswald Buddenhagen, 2013-04-06 :]
> > the .h file postprocessing in \subsubsection link_ui is a gross hack, and
> > i don't see any plausible reason why this should not be fixed in uic
> > instead.
> 
> I agree, but I saw it done like this so far in
> kdelibs/cmake/modules/kde4uic.cmake (lines 44-55),
>
"historical reasons".

> For example, one could add a single option for "ki18n support" (which
> I think would be too specific),
>
yeah, no-go.

> or maybe an option to include extra headers
>
qdbusxml2cpp already has an -i option for that purpose. i guess that
makes a good precedent.

as for the TRANSLATION_DOMAIN define, that really should come from the
build system to start with. it's always a bad idea to use defines which
configure headers in the sources themselves (you run into include order
problems really quickly).
fwiw, this also means that the trick suggested at the bottom of
klocalizedstring.h is not such a great idea (and to start with, to avoid
that the preprocessor floods you with redefinition warnings, the #undefs
have to come first, unconditionally).

> plus an option not to emit empty-string messages.
>
why an option? it's fairly pointless to emit tr()s for empty messages to
start with (and an empty message with a non-empty disambiguation has a
special meaning in linguist anyway).
fwiw, since qt 4.6, ui files support the notr attribute on (almost) all
strings, so it's already possible to suppress this stupid behavior
without postprocessing, even if it would be a tad laborious.

> And then maybe one should also consider the non-i18n related
> modifications performed in kde4uic.cmake.
> 
yeah. but that can be considered separately anyway.