qt-copy (or kde-qt) patches cleanup

[Oswald Buddenhagen]

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).
>
indeed.

> 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.