[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Translation Methods comparsion
From:       Dashamir Hoxha <dashohoxha () gmail ! com>
Date:       2013-04-02 16:10:20
Message-ID: CAMucfLz6f6Mq7KYbYOxqd7kLy319v=+UTtoXAN3JcM55=oSFYw () mail ! gmail ! com
[Download RAW message or body]

I can only agree with what Chusslove has written.
It is important to make a good analysis of the problem,
before trying to solve it.

I also think that the proposal of Kevin for uploading
external translations as review requests is the only way
that it can work properly, if some web-based translation
systems are going to be used. It can be improved a little
bit if "uploading" is done kind of automatically, on the
click of a button (from the web-based tool).

Also, one thing that can be considered is not using
the line diff tools (which usually give meaningless results),
but using pology to generate ediff (extended/embedded diffs,
whatever it means) which are usually meaningful for the
PO files.

Dashamir

On Tue, Apr 2, 2013 at 5:30 PM, Chusslove Illich <caslav.ilic@gmx.net> wrot=
e:
> Regarding the general idea of translatewiki.net-based translation workflo=
w
> for KDE, as expressed here:
>
>   https://translatewiki.net/wiki/Translating:KDE#Akademy_submission:_A_we=
b-based_translation_platform_for_KDE
>
> First, it is great to continually experiment with new tools and workflows=
.
> But, any new workflow has to cleanly interface with existing mechanisms, =
in
> order to demonstrate its advantages and disadvantages without too much
> disruption. This is what most of this thread has been so far. Furthermore=
, I
> think it is reasonable to make it a requirement that one or few complete
> language teams switch to the new workflow, to ease technical conflicts,
> providing that no work will be lost if a team decides to abandon that
> workflow after some time. Under these two conditions -- clean interfacing=
,
> easy abandoning -- experimenting is just fine.
>
> Second, I think that all existing web-based translation systems, includin=
g
> translatewiki.net, are decisively flawed at the core. (At least when appl=
ied
> to free software translation.)
>
> The major motivating assumption that these systems take is this: the flat=
ter
> the learning curve in translation-related tools, the more translations wi=
ll
> be made (for the set quality level). I haven't seen this assumption backe=
d
> up with numbers so far. As long as operating on gut feeling, my assumptio=
n
> is that "online" translators (those not willing to climb the "offline" to=
ol
> curve) will not be able to match either the quantity (summed over all
> contributors) or the quality of translation, compared to "offline"
> translators.
>
> The major technical drawback of web-based translation systems is that the=
y
> mix into one three distinct functions, that of translation hub, translati=
on
> editor, and translation checker. The result is that they are less efficie=
nt
> and less capable in any of these functions compared to dedicated standalo=
ne
> tools. Furthermore, since the tool is monolithic and remote, translators
> don't even get a shot at experimenting themselves with mixing in other
> tools.
>
> There are several counter-points made to this technical drawback, none of
> which is very valid. One is that translators no longer have to worry abou=
t
> particular translation file formats, as the web interface presents it all=
 in
> a uniform way. However, there are no "particular translation formats" in
> free software translations: there is pretty much only PO. That little whi=
ch
> is not PO, is first converted into PO for translation. Another counter-po=
int
> is that translators no longer have to deal with varying offline tools, su=
ch
> as particular VCS. This is also not true, because there are many web-base=
d
> translation systems, so translators now have to deal with varying online
> tools. Finally, it is said "if you wish, just export to PO, translate
> offline, then import back". This means that for that translator, the web-
> based system reduces to translation hub only, and a very inefficient one
> compared to a VCS.
>
> I will now directly address Niklas' motivation points on the above page:
>
>> I've seen the various file formats
>
> Quantitatively, I don't think this is significant for free software. When=
 a
> non-PO format is offered by the programmer, the best reply is "please swi=
tch
> to PO: it is the most supported format by free tools, as well as the most
> capable format on its own."
>
>> emailing files around
>
> It is easier to send by email than to upload. The idea here is that while=
 it
> is harder to upload, it will be less of a burden to integrate, which mean=
s
> more translations being made. This, however, still awaits the quantitativ=
e
> proof.
>
>> digging version control history to find changes
>
> There are two elements here. One is finding the particular version of a
> message, or listing different past versions, and another is having a prop=
er
> diff. Both these functions are poorly supported by line-based VCS, and th=
e
> solution is to use a PO-aware tool atop of a VCS. There is no implication
> that this tool must be part of a bigger monolithic program, and much less
> that it must be web-based.
>
>> read the source code to understand the context
>
> For real quality translation, this is, and probably will always be,
> necessary. What can be done, is to equip the translation editor with good
> automatic source reference resolving and display. Again, there is no
> implication of a web-based tool here.
>
>> proofread translations on a mailing list
>
> (Didn't understand this, unless part of the following.)
>
>> and waited months for my translations to end up in the product because o=
f
>> busy translation managers.
>
> The most review time is taken by -- review. Not by copying the file from
> whatever communication channel, not by opening it in editor, not by
> committing it. This is probably why I have been hearing the same complain=
t
> in context of web based tools ("I did it in Launchpad months ago, but noo=
ne
> approved it yet").
>
> It is true that the review process could be made more efficient. But, in =
my
> opinion, the usual approach to this ("the approver") is conceptually the
> same regardless of the tool, and that is the main problem in an environme=
nt
> with fluid contributor time.
>
> --
> Chusslove Illich (=D0=A7=D0=B0=D1=81=D0=BB=D0=B0=D0=B2 =D0=98=D0=BB=D0=B8=
=D1=9B)
[prev in list] [next in list] [prev in thread] [next in thread]