qt-copy (or kde-qt) patches cleanup

[Chusslove Illich]

>>> [: Oswald Buddenhagen :]
>>>   ~/qt/tranlations > lconvert qt_es.ts qt_es.po
>>>   ~/qt/tranlations > $ts_illiterate_app qt_es.po
>>>   ~/qt/tranlations > lconvert -locations relative qt_es.po qt_es.ts    # -locations is 4.6 syntax
>>>
>>> now, that was hard. ;)

>> [: Albert Astals Cid :]
>> That's three commands i didn't know they existed, you expect translators
>> (that remember usually are non technical people) to know them?

> [: 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. In those terms,
having individual translators run these commands is less efficient, will
cause less translations to be made, lead to more errors implying more
overhead communication, then the other solution.

The other, efficient solution, is that these commands are executed by
something which takes O(1) time to implement and maintain wrt. number of
languages, and invisibly to translators. Therefore it should be set up by
the application/library's maintainer.

Speaking of Qt in particular, I'd be entirely happy if there'd be a place
where we (= Scripty) could periodically download POTs (don't care how they
are made, so long as they are proper, see below), and a place where we could
periodically upload translated POs (don't care what is done with them, so
long as translations get used inside Qt). Whether this place is a VCS repo
or not, of which type it is, and where it is located, is not important.

There should also exist a spec-file with some general data, accessible
through a http:// URL. It would state the overall module name (e.g. qt), the
address for reporting bugs in messages, the contact address for procedural
issues, etc. It should have a section per each release branch from users'
viewpoint (e.g. stable, devel), stating the location to fetch POTs from
(e.g. an ftp:// or git:// URL), the location to put translated POs at, the
last date for accepting translations before the next release, etc. It should
be machine parsable and human readable; I think INI-style would be
sufficient (sections [general], [branch-stable], [branch-devel], ...).

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

* All messages are marked as fuzzy. Messages with empty msgstr field should
  not have this flag.

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

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. 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.
Otherwise, they could be put with a magic separator into msgctxt, e.g.
"QFileSystemModel|All other platforms".

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

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091001/9ee3f8d1/attachment.sig>