Translation in Qt5
ossi at kde.org
Wed Jul 6 13:38:45 BST 2011
On Tue, Jul 05, 2011 at 05:09:38PM +0200, Chusslove Illich wrote:
> [: Oswald Buddenhagen :]
> > if one defines that KUIT is a superset of qt rich text, there is not even
> > a theoretical problem with it.
> But KUIT is supposed to be transformable into different target formats, of
> which Qt rich text is one? (The other currently is plain text, and I've
> reserved "a slot" for shell color sequences.)
that doesn't matter. you can restrict the set of allowed tags per output
format. it's only important to recognize meaningful markup and reject
anything malformed. in the case of rich text output you can break out of
the theory and do pass-through of everything which is not for you - at
the risk of allowing stuff which will later break.
> First, some people really didn't like that semantic markup was thrown onto
> everyone, without possibility to disable it. This was mostly due to need to
> care about escaping.
i'm not overly concerned.
i'm sure somebody will complain if i make the new formatter reject
%blubb (requiring %%blubb) instead of silently passing it literally,
despite this being a very sane thing to do.
> The second problem is escaping and substitution. I tried briefly with auto-
> escaping, got regression reports in about a month, had to disable it.
well, of course *something* would regress when you change something so
the answer is the per-placeholder possibiliy to disable auto-quoting:
qTr("foo: %1 is %q2") % foo % bar;
("q" as in "pre-Quoted")
note that this quoting problem is not specific to semantic markup in any
> The third problem [...] When you have fixed semantic markup, there is
> the problem of set of tags. [...] So I went with a small set, and even
> myself am now not very happy at the choices I made.
> importantHighlight(i18n("Uses of") + " ") + nodes
> + importantHighlight(" " + i18n("from") + " ") + nodes + "<hr>";
that's easy ...
qTr("<m1>Uses of </m1> %1 <m1> from </m1> %2<hr>").markup("strong") % nodes % nodes;
did you have something like that in mind?
so in summary, you think we *should* go for semantic highlighting if the
problems can be adequately solved, yes?
More information about the kde-core-devel