From kde-core-devel  Mon Jul 04 14:46:27 2011
From: Chusslove Illich <caslav.ilic () gmx ! net>
Date: Mon, 04 Jul 2011 14:46:27 +0000
To: kde-core-devel
Subject: Re: Translation in Qt5
Message-Id: <201107041646.30165.caslav.ilic () gmx ! net>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=130979083431966
MIME-Version: 1
Content-Type: multipart/mixed; boundary="--nextPart3288584.IsEQy7jfsx"

--nextPart3288584.IsEQy7jfsx
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable

> [: Oswald Buddenhagen :]
> 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).

Mhmfh... that makes me even less happy then before :) Here is my strategic
opinion:

I don't think there is a clear benefit in unifying KDE and Qt translation
systems.

_From the point of view of Qt, considering their paying customers, why chan=
ge
anything in Linguist system? You said it yourself that you wouldn't bet a
snowflake in hell (perhaps in less colorful words) that anyone from that
side would care about translation scripting. As for semantic markup, did
really someone come to you and ask for *semantic* markup? Or there was
actually some other wish, which you thought could be served by semantic
markup? I ask because, if those two things would be factored out, everything
else would be just a change for the sake of change.

_From the point of view of KDE, I could imagine people had two benefits in
mind. One is that "code duplication" is reduced, making maintenance more
efficient and secure. But now you say you need a whole new person for the
job. I contend that some meet-you-half-way solution would take more effort
to maintain, due to the departure from the well-known paths and possible
counter-pulling forces[1], than the two systems would on their own[2]. The
other benefit was that one could use one and the same translation system in
both pure Qt and KDE projects; but this can be so anyway, since after
modularization of kdelibs, KDE translation system will be a standalone
library that could depend only on Qt[3].

[1] I saw a comment in Linguist DTD mentioning S60. Freaked me out.
Regardless of the context.

[2] On my part I can claim that maintaining KDE's translation system during
the last 5 years was a breeze. Just observe the repository logs. The worst
problem that we had was locking, since I have almost no experience with
multithreading, so at one point David Faure came around and locked it tight.

[3] It needs a string type, a few container types, IO streams, locks, an XML
parser, regexes, a locale facility, and a JS interpreter. All of this can be
provided by Qt (assuming John merges locale stuff there).

(I stop this message here, leave technical bits for next repl(y|ies).)

=2D-=20
Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)

--nextPart3288584.IsEQy7jfsx
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)

iEYEABECAAYFAk4R0kYACgkQMSGXgigGr3H5iQCeJ6QX7mIjNAPAxdsmSia2kFwa
GQ8An38aSaseJI+TEzEYCUgjvglSZD5P
=xi2W
-----END PGP SIGNATURE-----

--nextPart3288584.IsEQy7jfsx--