Translation in Qt5

[Oswald Buddenhagen]

On Sat, Jul 02, 2011 at 07:27:35PM +0200, Chusslove Illich wrote:
> When text contains markup, some special characters need to be escaped
> when they are wanted literally in the text.
>
that's why the decision whether QUIT (haha, what a pun) is wanted needs
to be done before 5.0.

> This leads to the possibility that some programmers will not want to use KUIT
> at all, and others may want to use it only on a subset of messages.
> Should this be allowed? If yes, should it be possible to activate/deactivate
> KUIT on message-by-message bases, or only globally (in some suitable sense)?
> 
right, now i remember that we talked about that.
auto-escaping is the only reasonable option. suppression should be done
on a per-placeholder basis (which brings us to rich formats again).
though i wonder how often you'd actually want to substitute a pre-quoted
string? i'd expect this to happen in cases where regular concatenation
is actually an option. counter-examples?

> 2. How to recover from markup errors?
> 
> A message with markup may end up invalid.

> Either due to literal typos, or,
>
that needs fixing.

> more importantly, through argument substitution without proper escaping.
>
and that should become a non-issue given my answer to 1). remaining
abuses need fixing, too.

consequently, no issue remains.

> 3. How to select output format?
> 
> Current state in KDE is that @-context markers determine the output format.
>
that sounds reasonable.

> 4. Mixing with other markup?
> 
> Normally mixing of markups is never allowed, but in the special
> circumstances we have, that is hardly a possibility.
>
one could also use a different syntax for the markup, think gmake
macros:
  "foo $(filename %1)"
or maybe qmake?
  "foo $$filename(%1)"
of course either would require some escaping stunts, etc.

anyway, i don't see anything wrong with the current state in kde. if one
defines that KUIT is a superset of qt rich text, there is not even a
theoretical problem with it.


what i'd expect now would be an actual use case for this stuff. you
indicated yourself that this is no high priority for you. why? did it
turn out less useful than anticipated? or too problematic (despite the
above answers)?


fwiw, somebody has to actually do the work if anything is supposed to
happen with qt's translation framework, and it doesn't look like any
troll has the capacity. we need to assess what is in kde, what can be
directly reused, what needs a rewrite, and who has time for it (contract
work may be an option).