Finalized proposal for changes to i18n in KF5

[Oswald Buddenhagen]

On Sat, Dec 22, 2012 at 10:44:22AM +0100, Chusslove Illich wrote:
> I have written up the headers and Doxygen pages for the Ki18n framework as
> it should finally look like, available here:
> 
excellent work.
though i was too lazy to make a real api review. ^^

of course, it would be even better if you strived for submission to
qt-project, if at all realistic (for now probably an add-on, but
definitely under cla). otherwise you'll see the same effect every other
useful lgpl'd qt framework sees sonner or later: it gets re-implemented
(if the effort is deemed acceptable by an interested party).

On Thu, Dec 27, 2012 at 12:45:37PM +0100, Chusslove Illich wrote:
> On Wed, Dec 26, 2012 at 05:10:59PM +0000, David Faure wrote:
> >   #define TRANSLATION_CATALOG "foolib"
> >   #include <klocalizedstring.h>
> >
> > [...] The #define will kill any "enable final" compilation support, but
> > then again I think this is gone anyway.
> 
> I expect that every group of source files that could be treated with enable-
> final, like one library, will have only one translation catalog. Then this
> #define-#include construct would be put in exactly one private header, which
> itself would have normal include guards, so enable-final would still work if
> it worked otherwise. Or am I missing something here?
> 
that's ok.
the other answer could be to make klocalizedstring.h #undef TRANSLATION_CATALOG
at the end (may need to use a macro indirection to ensure that the macro
is fully expanded already at definition time (see QT_STRINGIFY in qt 5)).

> >    #define i18n(...) i18nd(TRANSLATION_CATALOG, __VA_ARGS__)
> 
> Is this portable to all compilers supported by KDE?
> 
i wonder. see Q_COMPILER_VARIADIC_MACROS in
qt5/qtbase/src/corelib/global/qcompilerdetection.h


in http://nedohodnik.net/misc/ki18n-kf5-01/html/prg_guide.html "escaping", 
  xi18n("Installed Fooapp too old, need release <= 2.1.8.");
that needs to be >. :D

in "Phrase Tags", <bcode>, the example makes no sense, as there are no
linebreaks in the actual string.

the "<nl>" example is unfortunate, because it uses a sentence which
should end in a question mark ... but doesn't. "delete the following
files?<nl/>" would seem better to me.

i find the 5.0-superscripts in the tables way too noisy. alternative ideas:
- use a separate column
- just default to 5.0, and thus defer the problem (possibly
  indefinitely)
strictly speaking, the 5.0 is a lie anyway. ^^
in qt, we actually left in the 4.x version markers, to play in line with
the "mostly source-compatible" theme.

and as usual for native-only-in-slavic speakers, some "the"s are
missing. i was too lame to record their locations. ^^

your headers consistently have a space after function names. the kdelibs
coding style says something different ...

the "extern"s in front of the ki18n* declarations seem pointless and
untypical to me.


random ramblings:

i don't like the recommendation for extracted vs. disambiguating
comments (and closed-source authors will typically do the exact opposite
anyway). wouldn't it be sufficient for disambiguiation to strongly
recommend consistent use of user interface markers, and thus allow
all comments to be extracted? the matter of flagging changes is merely
tooling-related.

one thing i noticed while looking through catalogs is that it often
would be useful to be able to declare some kind of hierarchical
comments, so that a particular comment could apply to a whole group of
strings, without needing to replicate it, or relying on the translators'
ability to see the pattern themselves (which is a pipe dream, especially
if only some strings in an existing group changed). i suspect that this
may turn out "a bit" hard to implement without hacking gettext (and the
.po format) ...


regards