[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Translation Methods comparsion
From:       Lasse Liehu <lasse.liehu () gmail ! com>
Date:       2013-04-02 17:24:15
Message-ID: CAJa6Ua4o9UuEMgfVv7Kyk13oAAkMUvVgzKs8y9Nt=Vqy5N8qgA () mail ! gmail ! com
[Download RAW message or body]

On 1 April 2013 15:18, mvillarino <mvillarino@kde-espana.es> wrote:
>
> > Very crude* idea of how to handle conflicts using Lokalize:
>
> Please consider the following procedure:
>  online work proceeds only for kde trunk.
> b) periodically, the online tool issues a command that exports in a
> tarball or copies to an ad-hoc directory only those files that where
> newly created or modified files,
> b1) the files exported are flagged as "prefer mine full"
> b2) send the tarball to the coordination party (in short: if the local
> copy is dirty, let the coordinator know of your dust).
> c) the coordinator untars the online job in an ad-hoc directory (well,
> in my case it is at the this level:
>       /path_to/KDE/trunk/l10n-kde4/.
> aside: given the volume of work for my team, I copy the po files
> directly onto by working copy. Only each now and them I do some test
> just to check what is people actually doing.
>
> What should happen now ? I consider that it should be:
> d) the script changes working directory to
> /path_to/KDE/trunk/l10n-kde4/onliners/ (for instance)
> e) for each file in the pwd, if no such file in the working copy, move
> the file there, svn add it there  and delete here.
> f) the script launches lokalize with the right project.
> g) for each remaining file in onliners, in lokalize ope an editor for
> it, and attach the file in onliners as an alternate tranlation file or
>  something like that.

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

> 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).

> 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.

What does "to not use mine conflict" in i1 mean?

> 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.

> 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?
[prev in list] [next in list] [prev in thread] [next in thread]