Translation in Qt5
caslav.ilic at gmx.net
Mon Jul 4 15:46:27 BST 2011
> [: 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
I don't think there is a clear benefit in unifying KDE and Qt translation
_From the point of view of Qt, considering their paying customers, why change
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, than the two systems would on their own. 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.
 I saw a comment in Linguist DTD mentioning S60. Freaked me out.
Regardless of the context.
 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.
 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).)
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel