RFC: i18n: drop KUIT tags in KDE Frameworks 5.0?

[Albert Astals Cid]

El Dissabte, 24 de març de 2012, a les 11:03:32, Chusslove Illich va escriure:
> >> [: Thomas Zander :]
> >> But can we be certain enough of succeeding now where we clearly failed
> >> before that this is actually worth stopping the innovations that
> >> Chusslove is working on?
> > 
> > [: Albert Astals Cid :]
> > I did not understand that it was stopping any innovation, Chusslove can
> > you clarify if you want to remove them for the sake of simpler code (which
> > I don't say it's unimportant) or because they create problems with other
> > features you are developing?
> 
> It's not stopping any innovation as such, since I just want to drop it and
> add nothing new. But the system cannot remain as it is, because of too many
> quirks. To remain, it would have to be fixed, and to be made optional. Both
> these aspects are problematic.
> 
> "Fixed" would make it require more discipline. For example, one could no
> longer do:
> 
>   QString problem = i18n("Blah blah <emphasis>foom</emphasis>.");
>   ...
>   QString report = i18n("Blah blah: <note>%1</blah>", problem);
> 
> because substitution would cause autoescaping of any target format tags
> (e.g. if <emphasis> was turned into <i>), and show them verbatim. Instead,
> one would have to do:
> 
>   KLocalizedString problem = ki18n("Blah blah <emphasis>foom</emphasis>.");
>   ...
>   QString report = i18n("Blah blah: <note>%1</blah>", problem);
> 
> as only KLocalizedString as argument would not be autoescaped (it would be
> enforced to be valid wrt. markup).

Discipline is not a problem, we are used to the compiler complaining when we 
use . instead of -> even if it is obviously what we meant. In fact one of the 
problems with the current system is that if you do i18n("Foo %1").arg("LALA") 
it still works (depending on the type of kdelibs build you have). It should 
totally break and then the developer will realize he's doing something wrong.

> "Optional" would cause uncertainty. One could not count on KUIT being
> available in a particular section of code, but would have to check 1) which
> catalog are messages looked up in 2) does that catalog have KUIT enabled
> (optionality would be by-catalog). That someone in doubt does not have to be
> a human, but also source code/translation validation tool.

I agree optional is a bad idea.

> These two implications, combined with low usage as it is, makes me conclude
> it is not worth investing the work in fixing the system. Higher discipline
> and more uncertainty would mean even less people would use it than they do
> now.

That's fine you're the one doing the work and I'm not going to do it nor try 
to force you to do it.

OTOH it's another hurdle for adoption of current code from KDE 4 to KF5, that 
originally was said to be "transparent" for developers and each day is getting 
to look more like a bigger change.

Cheers,
  Albert

> 
> (The stakes are somewhat different for the more radically new system that I
> describe in that proposal for extending Gettext. The higher discipline
> requirement would remain, but is (supposed to be) offset by the fact that
> you could use the exact same i18n in any programming language and toolkit,
> providing availability of bindings, and use arbitrary target visual formats
> transparently for translators; i.e. translators would no longer see the
> underlying programming framework. The uncertainty aspect would be mostly
> removed, because new option to xgettext would be used on extraction, and all
> messages in PO file would get appropriate *-format flag, whether they have
> any placeholder or not.)