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

List:       kde-i18n-doc
Subject:    Re: Translation verification: using diffs
From:       Dashamir Hoxha <dashohoxha () gmail ! com>
Date:       2013-06-01 17:04:18
Message-ID: CAMucfLzCoPCtxbfOiPMSxKxcL+RPM75zrs5J==BaJOfWFCOjig () mail ! gmail ! com
[Download RAW message or body]

As pointed out, when there are small changes to many files,
reviewing all the of them one by one may be tedious (and KDE
does have lots of files). I can imagine that it may not be very
difficult to extend Lokalize to 'Sync/merge' two different directories
(or projects) instead of two different files, but since it does not
have that feature yet, that task remains difficult.

In this case using Pology can be more efficient. Besides this,
the real strength of Pology is for making automatic checks
and verifications. It can take some time to manage it, but in
the long run it can pay and be very helpful.

Dashamir

On Sat, Jun 1, 2013 at 6:19 PM, Marta Rybczynska <rybczynska@gmail.com> wro=
te:
> Hello all,
> First big thanks for all responses. I have learned multiple methods I can
> try. I've done some experiments and Dashamir's solution with Lokalize's S=
ync
> option works very well for separate files. I will be also looking at the
> pology-based solution in the future to make some automatic updates, I thi=
nk
> it is possible.
>
> Thanks all,
> Marta
>
>
> On Thu, May 30, 2013 at 4:41 PM, Chusslove Illich <caslav.ilic@gmx.net>
> wrote:
>>
>> > [: Dashamir Hoxha :]
>> > Regarding the approach that I described (using the sync/merge features
>> > of
>> > Lokalize). [...] I am not very familiar with the details of KDE
>> > translation process, and more importantly I have not actually tried it
>> > on
>> > KDE [...]
>>
>> The approach you described, if I understood correctly, is exactly the
>> approach that Freek and mvillarino have described as using it. And I
>> vaguely
>> recall from earlier threads that some other people are using it too. So =
it
>> can be said that it is used regularly for KDE too.
>>
>> > It seems simple and intuitive to me [...] But I would also like to kno=
w
>> > when are the cases that it can fail, and how it can fail. Knowing thes=
e
>> > cases can be useful for deciding whether to use it or not in certain
>> > situations, when to use it and when not.
>>
>> One little technical issue has been mentioned by Freek, that there is no
>> way
>> to jump through messages with equal original and modified translation.
>> This
>> issue is little in the sense of being fixable by adding one more action =
or
>> option in the Go menu, while for me the current state would be a deal-
>> breaker (I ask people to make whatever modifications they see as good,
>> whenever they get to it).
>>
>> Instead, the main problems are conceptual. One problem is that people
>> again
>> need to send PO files around, which breaks as soon as one wants to make
>> small updates to many files. Another problem is that a modified PO file =
is
>> either reviewed or not when committed, and that will cause review holdup=
s,
>> or, worse yet more usual, less thorough reviews. Then, there is no
>> effective
>> way for multiple people to perform review, for different types of
>> reviews[*], or for later double-check. Finally, there is no separation
>> between the editing system (translation editor) and the review system,
>> leading to monolithic-tool lock-in.
>>
>> [*] This is actually the initial requirement I had, from which I grew th=
e
>> ascription system in Pology.
>>
>> > [...] and it can be used for any kind of .po files (not only for KDE).
>>
>> The ascription system too can handle any kind of PO files, not only from
>> KDE. However, it does require the existence of by-language collections o=
f
>> PO
>> files inside a VCS repository, with commit/push access for recurrent
>> translators. That this is fulfilled up-front for KDE PO files is the gre=
at
>> strength of the KDE Translation Project.
>>
>> --
>> 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]