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