qt-copy (or kde-qt) patches cleanup

Oswald Buddenhagen ossi at kde.org
Fri Oct 2 13:14:47 BST 2009

hi chusslove,

thanks for the detailed examination.

On Thu, Oct 01, 2009 at 05:33:56PM +0200, Chusslove Illich wrote:
> >>> [: Oswald Buddenhagen :]
> > i'm sure you have guidelines nicely assembled in a wiki and channels to
> > get individiual help. it's reasonable to expect that you (translators)
> > will manage, now that you know how. :)
> Before considering how hard something is, I like to consider how efficient
> it is, in terms of total time spent per set quality level. [...]
> [ideas]
the side of distributing current templates is certainly doable.
however, it won't work for the submissions. in either case it is a
highly individual process, and either fairly technical or with some
one-time paper chase.

> As for lconvert, which I assume would be used to create POTs, I've now
> tested:
>   $ lconvert qt_untranslated.ts -o qt.po && mv qt.po qt.pot
> (-o qt.pot just copied over TS content, Qt 4.5.2).
looks like a non-feature. :)

> I see the following problems in the POT file obtained in this way:
> * The header is not valid, having only the X-Virgin-Header field. It
>   should look like a header out of xgettext, none of the fields it
>   provides are superfluous.
hmm, most of the fields either have no representation in TS (i.e.,
lconvert would have to pull something out of thin air) or are
represented in an incompatible way.

> * All messages are marked as fuzzy. Messages with empty msgstr field should
>   not have this flag.
yeah, i wasn't sure about the semantics. will fix.

> * Messages with format directives (%1, %2... %n in plural messages) should
>   have the flag qt-format.
good point.

> Concerning semantics of Qt automatic contexts, I would have nothing against
> (would even prefer) if they would go into PO msgctxt, due to stronger
> disambiguation.
i considered that and didn't like it.
you may also want to have a look at the XLIFF output we produce; i had
problems coming up with good mappings here, too.

> But then it would be necessary to do something else with manual
> contexts (that which lconvert currently puts into msgctxt).

> One solution could be to put *them* instead into #. ... comments, if
> no two messages would fold into one when having automatic context in
> msgctxt.
sounds too blurry. a comment's location would be influenced by
adding/removing other messages.

> Otherwise, they could be put with a magic separator into msgctxt, e.g.
> "QFileSystemModel|All other platforms".
that would be an interesting solution if we actually wanted to be able
to feed a QTranslator with MO files generated from such PO files with an
unpatched msgfmt. i see no use case for that, though.
i'm somewhat concerned about treating msgctxt fields magically when
converting back to TS - there might be |s which mean nothing. maybe use
an "X-TS-Contexts: yes" in the file header ...
anyway, do you think doing this would be a significant improvement of
the regular "translation experience"? i thought the formalized comments
would be prominent enough.

> Another issue to be handled are Qt's hardcoded plural formulas. If it would
> be possible to take over a plural formula from the PO, and use it for that
> particular TS, that should be done.
qt's approach is unfortunately diametrically opposite to gettext's.
converting between the formulas in an efficient way is probably material
for a master thesis ...

> Otherwise, Qt should maintain the list of Gettext formulas equivalent
> to Qt's, per language, so that we can enforce it in translated POs on
> our side.
will do that. i wonder if it is legal to simply copy the formulas from
gettext ...

> The file with this list should be placed together with POTs, and be in
> sync with the Qt release to which the POTs are targeted.
i don't get your point here.

More information about the kde-core-devel mailing list