[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-i18n-doc
Subject: Re: Translation Methods comparsion
From: mvillarino <mvillarino () kde-espana ! es>
Date: 2013-04-02 18:31:59
Message-ID: CAGOKLE-1BQPgirDtMFeku-pggmd_UWBDgfpATM7O50W4iHfDoA () mail ! gmail ! com
[Download RAW message or body]
Hi,
> The idea in that was to use Lokalize's Primary Sync [1]. A po file in
> SVN would be the base file and its corresponding file in the onliners
> directory would be the one to merge. I just wrote that idea down
> without thinking through if and how it could be implemented. Neither
> am I sure if it's at all a good way to do it.
>
> [1] http://docs.kde.org/stable/en/kdesdk/lokalize/sync.html
Yes,I made the mistake to mention secondary sync instead of primary. My
guilt.
> > h) at this point, the ideal would be to instrude lokalize to show just
> > those translation unit for wich there is an alternate translation
> > (different from the one currently in the file in the working copy).
>
> There are shortcuts for going through only those messages. Alt+Down
> and Alt+Up by default (described in the Lokalize handbook).
Yes, there they are. But I find more confortable the way pology's posieve
shows it's matched messages: just show them in the messages list, and only
move through the matched messages with the prev/next shortcuts.
> > i) To the dirty job: go take a look at each alternate translation and
> > accept it if the coordinator thinks it's fine.
> > i1) Add a command to lokalize alternate translation view, to be able
> > to discard an alternative. If it is used, the online tool should be
> > notified to not use mine conflict on svn up.
> > i2) Add a command to lokalize in order to notify the online tool when
> > a file has been totally accepted, so reject mine conflict.
> > j) Commit and notify the online tool
>
> To clarify: if done this way, there are no local changes the in the
> SVN checkout of pot and po files at TranslateWiki. This is because the
> changes are made in its database and then exporting the changes to
> commit them in SVN generates the po files to a wanted, usually
> another, location.
>
Oh, lovely! The internals of TrWiki is not an important fact here, but you
are already able to export all of your files to somewhere.
Please note that I consider that other location to be a "working copy in
coordinators hands". This doesn't imply that in this case it should be in
my hands, but in some natural person's hands.
> What does "to not use mine conflict" in i1 mean?
This is the more tricky part of the game.
You'll understand that when talking about a repository with so many dozens
of files, it is not uncommon to deal with six, seven, or more files with
conflicts, particularly if people working with desktop tools sends you
outdated files, or if you keep a contributed file several days on your
working copy and then try to commit it... well, there are several
situations to care of.
And this takes time, that scant resource. So any mean to magically deal
with this is welcome.
The magic i use is"svn resolve --accept mine-full
${onliners}/${module}/${file}" each file with conflicts. Then a
trunk/scripts/merge.sh updates to the freshest pot, and there you are, with
up-to-date po files with the newest contributions.
This works because only two hands touch the repository, and just one gropes
the msgstr.
With one more party, this gets not so linear. So trying to keep a single
write-access working copy is desirable.
The remainder of the proposed working procedure tries to adhere to
this wish.
> > k) The coordinator then proceeds with files from desktopers (by using
> > the same tools on different pwd).
> >
> >
> > l) The online tool then waits for scripty and updates. If the update
> > brings in conflicts, the files notified as ready for a
> > theirs-conflicts resolve by accepting the files from scripty,
> > otherwise mine-conflicts is the way.
> > ... so online keeps the files which has not been fully reviewed
> > (and commited) by coordinator, and gets po files updated from scripty.
> Operating that way on a file basis feels risky because I didn't quite
> understand the way conflict resolving modes are changed according to
> your description and thus what they imply.
If the file has not been touched online then the online tool can safely
update it. In case of conflict, accept theirs-conflict.
If the file is sent to the commiter, and he reviewes the file and accepts
it FULLY (:=all of the modified transtion units), and commits the resulting
file, then the online tool can safely update it. In case of conflict,
accept theirs-conflict.
If the file is sent to the commiter, and he reviewes the file and accepts
it NOT(FULLY) (:= some of the transtion units modified online where
rejected), and commits the resulting file, then the online tool should
consider to forget about the local modifications and accept the file in kde
repo. In case of conflict, accept theirs-conflict.
Otherwise, just svn update, and if conflicted, keep mine-conflict (in svn
resolve, i mean).
Personally, I just review new contributors work in theyr early days. Most
of the time I just accept their work as is, looking at the internals just
four or five times a year per contributor. Nevertheless, this step is
unavoidable for newcomers and despite of he who commits being a desktop
tools lover or an online tools lover, it MUST be done (and we know you
will). ;-).
> > One every check-kde-tp run is acceptable.
> How often does it run and is the interval regular? Did you mean that
> TranslateWiki would do an import each time the check has finished?
>
Yeah, it's aproximately weekly. More than enough for a pilot test.
Depending on the real life work load I have, it would be desirable to
update even every other week.
Hope this helps.
Kind regards,
Marcelino
[Attachment #3 (text/html)]
<div dir="ltr"><div style>Hi,</div><div class="gmail_extra"><div \
class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class=""><div class="h5">
<br>
</div></div>The idea in that was to use Lokalize's Primary Sync [1]. A po file \
in<br> SVN would be the base file and its corresponding file in the onliners<br>
directory would be the one to merge. I just wrote that idea down<br>
without thinking through if and how it could be implemented. Neither<br>
am I sure if it's at all a good way to do it.<br>
<br>
[1] <a href="http://docs.kde.org/stable/en/kdesdk/lokalize/sync.html" \
target="_blank">http://docs.kde.org/stable/en/kdesdk/lokalize/sync.html</a></blockquote><div><br></div><div \
style>Yes,I made the mistake to mention secondary sync instead of primary. My \
guilt.</div> <div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="im"> > h) at this point, the ideal would be to instrude lokalize to show \
just<br> > those translation unit for wich there is an alternate translation<br>
> (different from the one currently in the file in the working copy).<br>
<br>
</div>There are shortcuts for going through only those messages. Alt+Down<br>
and Alt+Up by default (described in the Lokalize \
handbook).</blockquote><div><br></div><div style>Yes, there they are. But I find more \
confortable the way pology's posieve shows it's matched messages: just show \
them in the messages list, and only move through the matched messages with the \
prev/next shortcuts.</div> <div><br></div><div> </div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="im"> > i) To the dirty job: go take a look at each alternate translation \
and<br> > accept it if the coordinator thinks it's fine.<br>
> i1) Add a command to lokalize alternate translation view, to be able<br>
> to discard an alternative. If it is used, the online tool should be<br>
> notified to not use mine conflict on svn up.<br>
> i2) Add a command to lokalize in order to notify the online tool when<br>
> a file has been totally accepted, so reject mine conflict.<br>
> j) Commit and notify the online tool<br>
<br>
</div>To clarify: if done this way, there are no local changes the in the<br>
SVN checkout of pot and po files at TranslateWiki. This is because the<br>
changes are made in its database and then exporting the changes to<br>
commit them in SVN generates the po files to a wanted, usually<br>
another, location.<br></blockquote><div><br></div><div style>Oh, lovely! The \
internals of TrWiki is not an important fact here, but you are already able to export \
all of your files to somewhere.</div><div style><br></div> <div style>Please note \
that I consider that other location to be a "working copy in coordinators \
hands". This doesn't imply that in this case it should be in my hands, but \
in some natural person's hands.</div> <div><br></div><div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
What does "to not use mine conflict" in i1 \
mean?</blockquote><div><br></div><div style>This is the more tricky part of the \
game.</div><div style><br></div><div style>You'll understand that when talking \
about a repository with so many dozens of files, it is not uncommon to deal with six, \
seven, or more files with conflicts, particularly if people working with desktop \
tools sends you outdated files, or if you keep a contributed file several days on \
your working copy and then try to commit it... well, there are several situations to \
care of.</div> <div style>And this takes time, that scant resource. So any mean to \
magically deal with this is welcome.</div><div style><br></div><div style>The magic i \
use is"svn resolve --accept mine-full ${onliners}/${module}/${file}" each \
file with conflicts. Then a trunk/scripts/merge.sh updates to the freshest pot, and \
there you are, with up-to-date po files with the newest contributions.</div> <div \
style><br></div><div style>This works because only two hands touch the repository, \
and just one gropes the msgstr.</div><div style><br></div><div style>With one more \
party, this gets not so linear. So trying to keep a single write-access working copy \
is desirable.</div> <div style> The remainder of the proposed working procedure \
tries to adhere to this wish.</div><div> <br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> k) The coordinator then proceeds with files from desktopers (by using<br>
> the same tools on different pwd).<br>
><br>
><br>
> l) The online tool then waits for scripty and updates. If the update<br>
> brings in conflicts, the files notified as ready for a<br>
> theirs-conflicts resolve by accepting the files from scripty,<br>
> otherwise mine-conflicts is the way.<br>
> ... so online keeps the files which has not been fully reviewed<br>
> (and commited) by coordinator, and gets po files updated from scripty.<br>
</div>Operating that way on a file basis feels risky because I didn't quite<br>
understand the way conflict resolving modes are changed according to<br>
your description and thus what they imply.</blockquote><div><br></div><div style>If \
the file has not been touched online then the online tool can safely update it. In \
case of conflict, accept theirs-conflict.</div><div style> If the file is sent to the \
commiter, and he reviewes the file and accepts it FULLY (:=all of the modified \
transtion units), and commits the resulting file, then the online tool can safely \
update it. In case of conflict, accept theirs-conflict.</div> <div style>If the file \
is sent to the commiter, and he reviewes the file and accepts it NOT(FULLY) (:= some \
of the transtion units modified online where rejected), and commits the resulting \
file, then the online tool should consider to forget about the local modifications \
and accept the file in kde repo. In case of conflict, accept theirs-conflict.<br> \
</div><div style>Otherwise, just svn update, and if conflicted, keep mine-conflict \
(in svn resolve, i mean).</div><div style><br></div><div style><br></div><div \
style>Personally, I just review new contributors work in theyr early days. Most of \
the time I just accept their work as is, looking at the internals just four or five \
times a year per contributor. Nevertheless, this step is unavoidable for newcomers \
and despite of he who commits being a desktop tools lover or an online tools lover, \
it MUST be done (and we know you will). ;-).</div> <div> </div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div \
class="im"> > One every check-kde-tp run is acceptable.<br>
</div>How often does it run and is the interval regular? Did you mean that<br>
TranslateWiki would do an import each time the check has finished?<br>
</blockquote></div><br></div><div class="gmail_extra" style>Yeah, it's \
aproximately weekly. More than enough for a pilot test. Depending on the real life \
work load I have, it would be desirable to update even every other week.</div> <div \
class="gmail_extra" style><br></div><div class="gmail_extra" style>Hope this \
helps.</div><div class="gmail_extra" style><br></div><div class="gmail_extra" \
style>Kind regards,</div><div class="gmail_extra" style>Marcelino</div> </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic