From kde-i18n-doc Thu Apr 04 14:04:18 2013 From: Lasse Liehu Date: Thu, 04 Apr 2013 14:04:18 +0000 To: kde-i18n-doc Subject: Re: Translation Methods comparsion Message-Id: X-MARC-Message: https://marc.info/?l=kde-i18n-doc&m=136508427430549 On 2 April 2013 21:31, mvillarino wrote: >> 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. Sounds nice. > 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. Of course. > 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. Noted. Also as a fellow translator, thanks for merge.sh, didn't know about it. > 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). So in other words: * If a file has not been changed in Translatewiki, bring all changes from SVN. In case of conflicts, select the SVN version. * If a file was changed in Translatewiki, and all those changes have already been put in SVN, bring all changes from SVN. In case of conflicts, select the SVN version. * If a file was changed in Translatewiki, the file has been reviewed, and only some changes were accepted and put in SVN, bring all changes from SVN. In case of conflicts, select the SVN version. So that the result is that the rejected translations in Translatewiki are replaced by the current SVN version. * Otherwise bring all changes from SVN. In case of conflicts, select the version in Translatewiki. Except if the message was marked as discarded (i2), then select the SVN version. "i2) Add a command to lokalize in order to notify the online tool when a file has been totally accepted, so reject mine conflict." > 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). ;-). Yes, the need for review cannot be denied. > 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. OK. > Hope this helps. That was useful. Thanks, Lasse