[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-i18n-doc
Subject: Re: Translation verification: using diffs
From: Marta Rybczynska <rybczynska () gmail ! com>
Date: 2013-06-01 16:19:33
Message-ID: CAApg2=RiHsQoyZqhLBsuQ9zn+woKhmsGBOD_e=+zh_kAopDP=w () mail ! gmail ! com
[Download RAW message or body]
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
Sync 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
think it is possible.
Thanks all,
Marta
On Thu, May 30, 2013 at 4:41 PM, Chusslove Illich <caslav.ilic@gmx.net>wrot=
e:
> > [: 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 i=
t
> can be said that it is used regularly for KDE too.
>
> > It seems simple and intuitive to me [...] But I would also like to know
> > when are the cases that it can fail, and how it can fail. Knowing these
> > 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. Th=
is
> issue is little in the sense of being fixable by adding one more action o=
r
> 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 aga=
in
> 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 i=
s
> either reviewed or not when committed, and that will cause review holdups=
,
> 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 the
> 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 of
> 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 grea=
t
> 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)
>
[Attachment #3 (text/html)]
<div dir="ltr"><div><div><div>Hello all,</div>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 Sync 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 think it is possible.<br> <br></div>Thanks \
all,<br></div>Marta<br></div><div class="gmail_extra"><br><br><div \
class="gmail_quote">On Thu, May 30, 2013 at 4:41 PM, Chusslove Illich <span \
dir="ltr"><<a href="mailto:caslav.ilic@gmx.net" \
target="_blank">caslav.ilic@gmx.net</a>></span> wrote:<br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">> [: Dashamir Hoxha :]<br> <div class="im">> Regarding \
the approach that I described (using the sync/merge features of<br> </div>> \
Lokalize). [...] I am not very familiar with the details of KDE<br> <div \
class="im">> translation process, and more importantly I have not actually tried \
it on<br> </div>> KDE [...]<br>
<br>
The approach you described, if I understood correctly, is exactly the<br>
approach that Freek and mvillarino have described as using it. And I vaguely<br>
recall from earlier threads that some other people are using it too. So it<br>
can be said that it is used regularly for KDE too.<br>
<br>
> It seems simple and intuitive to me [...] But I would also like to know<br>
<div class="im">> when are the cases that it can fail, and how it can fail. \
Knowing these<br> > cases can be useful for deciding whether to use it or not in \
certain<br> > situations, when to use it and when not.<br>
<br>
</div>One little technical issue has been mentioned by Freek, that there is no \
way<br> to jump through messages with equal original and modified translation. \
This<br> issue is little in the sense of being fixable by adding one more action \
or<br> option in the Go menu, while for me the current state would be a deal-<br>
breaker (I ask people to make whatever modifications they see as good,<br>
whenever they get to it).<br>
<br>
Instead, the main problems are conceptual. One problem is that people again<br>
need to send PO files around, which breaks as soon as one wants to make<br>
small updates to many files. Another problem is that a modified PO file is<br>
either reviewed or not when committed, and that will cause review holdups,<br>
or, worse yet more usual, less thorough reviews. Then, there is no effective<br>
way for multiple people to perform review, for different types of<br>
reviews[*], or for later double-check. Finally, there is no separation<br>
between the editing system (translation editor) and the review system,<br>
leading to monolithic-tool lock-in.<br>
<br>
[*] This is actually the initial requirement I had, from which I grew the<br>
ascription system in Pology.<br>
<br>
> [...] and it can be used for any kind of .po files (not only for KDE).<br>
<br>
The ascription system too can handle any kind of PO files, not only from<br>
KDE. However, it does require the existence of by-language collections of PO<br>
files inside a VCS repository, with commit/push access for recurrent<br>
translators. That this is fulfilled up-front for KDE PO files is the great<br>
strength of the KDE Translation Project.<br>
<div class="HOEnZb"><div class="h5"><br>
--<br>
Chusslove Illich (Часлав Илић)<br>
</div></div></blockquote></div><br></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic