From kde-i18n-doc Tue Apr 02 18:31:59 2013 From: mvillarino Date: Tue, 02 Apr 2013 18:31:59 +0000 To: kde-i18n-doc Subject: Re: Translation Methods comparsion Message-Id: X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=136492754110740 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--047d7b5d4782f9b98d04d964f3a1" --047d7b5d4782f9b98d04d964f3a1 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b5d4782f9b98d04d964f3a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
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<= /blockquote>

Yes,I made the mistake to mention sec= ondary sync instead of primary. My guilt.
=A0
> 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 i= n the messages list, and only move through the matched messages with the pr= ev/next shortcuts.

=A0
> i) To the dirty job: go take a look at each alternate translation and<= br> > accept it if the coordinator thinks it's fine.
> =A0i1) Add a command to lokalize alternate translation view, to be abl= e
> to discard an alternative. If it is used, the online tool should be > notified to not use mine conflict on svn up.
> =A0i2) Add a command to lokalize in order to notify the online tool wh= en
> 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! Th= e internals of TrWiki is not an important fact here, but you are already ab= le to export all of your files to somewhere.

Please note that I consider that other location to be a "wo= rking 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.

=A0
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 r= epository 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 s= everal days on your working copy and then try to commit it... well, there a= re several situations to care of.
And this takes time, that scant resource. So any mean to magical= ly deal with this is welcome.

The magi= c 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 newe= st 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 si= ngle write-access working copy is desirable.
=A0 =A0 =A0The remainder of the proposed working procedure tries= to adhere to this wish.
=A0
> k) The coordinator then proceeds with files from desktopers (by using<= br> > 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 =A0by accepting the files from scripty,
> otherwise mine-conflicts is the way.
> =A0 =A0 ... so online keeps the files which has not been fully reviewe= d
> (and commited) by coordinator, and gets po files updated from scripty.=
Operating that way on a file basis feels risky because I didn't q= uite
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 safe= ly update it. In case of conflict, accept theirs-conflict.
If the file is sent to the commiter, and he reviewes the file and accepts i= t FULLY (:=3Dall of the modified transtion units), and commits the resultin= g file, then the online tool can safely update it. In case of conflict, acc= ept theirs-conflict.
If the file is sent to the commiter, and he reviewes the file an= d accepts it NOT(FULLY) (:=3D some of the transtion units modified online w= here rejected), and commits the resulting file, then the online tool should= consider to forget about the local modifications and accept the file in kd= e repo. =A0In case of conflict, accept theirs-conflict.
Otherwise, just svn update, and if conflicted, keep mine-c= onflict (in svn resolve, i mean).


=
Personally, I just review new contributors work in theyr e= arly 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, thi= s step is unavoidable for newcomers and despite of he who commits being a d= esktop tools lover or an online tools lover, it MUST be done (and we know y= ou will). ;-).
=A0
> One every check-kde-tp run is acceptable.
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?

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 othe= r week.

Hope this helps.

Kind regards,
Marcelino
--047d7b5d4782f9b98d04d964f3a1--