Translation in Qt5

Oswald Buddenhagen ossi at
Thu Jun 30 09:15:11 BST 2011

On Wed, Jun 29, 2011 at 09:04:40PM +0100, John Layt wrote:
> * New QStringFormatter to solve tr() args problem.  Community to code? [I 
> don't understand the problem or solution here :-)]
the problems to solve:
- localization-specific string formatting, i.e., making the format part
  of the translation (think sprintf), not hard-coded arguments to arg()
- remove qt's dichotomy to have either an .arg().arg().arg() chain (and
  potentially resulting double expansion problems) or only string
  arguments when using multi-argument arg()

the solution is something which resembles boost::format:
  QString str = QStringFormatter("Hello %1") % "World";

for advanced formatting, i'm envisioning the syntax %[12.34h]1, i.e.,
sprintf-like options in brackets.

i wonder whether it would be useful to embed date/time formatting into
this? it sounds doable in any case.

this should be done first. i want the upcoming qTr() to return a
QStringFormatter object.

> * Semantic markup wanted: copy KUIT from KDE, inline markup do rewrite to 
> Chusselove's revised design.
- i think we can simply copy the i18n @tags. it's just a convention, so
  code-wise a zero-effort endeavour. this enables us to drop the class
  contexts (which are annoying and solve only part of the problem)
- for the inline markup, chusslove gave me a list with 10-15 items when
  i asked "what would you do differently if you could do KUIT again?".
  half of it is all greek to me, so somebody actually familiar with the
  code and spec needs to take up on that.

> * Not yet willing to consider KDE's Transcript scripting, would prefer other 
> industry solutions to be investigated first.
something got mangled on the way ...
i simply don't see much point in translation scripting, having seen how
commercial translators work (there is no frigging way they would spend
time on properly scripting stuff). consequently, there are no industry
solutions for that, either. at least i know none.
but i'm not really opposed to it, assuming it isn't too heavy code-wise.
with JS being a 1st class citizen in qt anyway, it should come rather

> * Ossi to do a high-level write-up of the changes so others know what he 
> wants.
wait, when did i say that? :D
denis is supposed to put the meeting minutes on the wiki (and i guess
these two mails should be a pretty good basis). with some amendments,
this could be the authoritative source.

More information about the kde-core-devel mailing list