[Kde-scm-interest] A concept for "moving to Git" and translations

[Chusslove Illich]

First of all, "moving to Git" is under quotes because it's, in my view, a
misnomer for what should really be done to properly reorganize the things,
such that we do not set ourselves up for a similar trouble in the
foreseeable future, and provide even more flexibility right after its up and
running. What we need is separation, decoupling of translators' and
programmers' facilities, such that one does not influence the other, save
through a well-defined internal bridge which few people can maintain. The
idea is that translators can pick their own VCS (and/or something else), and
likewise maintainers of an app or a complete core module.

While I personally don't like messing with Scripty as it is further and
advised against it, it *can* be made to work as above, i.e. to make things
no worse (or marginally worse) for the few overall i18n maintainers, *and*
introduce *no* changes for translators in general.

It's conceptually simple. Modify Scripty such that a random app, with its
random separate repo and VCS (be it Subversion, Git, etc.) can just put a
few lines in a particular Scripty's register file, which will map it's repo
locations/branches to what Scripty should fetch, extract, and commit to. For
example:

  [amarok]
  section = extragear
  subsection = multimedia
  vcs = git
  repo-base = git://foo.bar.kde/amarok
  ui-stable = src at branch_2_0
  ui-trunk = src at master
  doc-stable = doc at branch_2_0
  doc-trunk = doc at master

All Scripty's VCS ops should be modularized, such that it has (in SVN
terminology) checkout_branch, update_branch, commit_dir, commit_file, etc.
which will do the right thing for a VCS given by vcs key when given value
repo-base, one of ui-stable etc., a file or dir path, and whetever other
argument necessary for the operation. *-stable and *-trunk here are names of
translators' branches, which are merely according to current translators'
convention, but from Scripty's point of view could very well be *-stable and
*-unstable (which I'd prefer, as they do not imply VCS branches, which they
shouldn't).

For example, by the above setup, to create stable POT Scripty should clone
(on first run, later whatever least bandwidth) git://foo.bar.kde/amarok,
switch to its branch_2_0, go into src/ do the extraction (run
messages-extract.sh, etc.) and commit the POTs (there will be at least
desktop_* too, and any number of POs for apps/modules in general) into
svn://svn.kde.org/home/kde/branches/stable/l10n-kde4/templates/messages/extragear-multimeda/
.

Or, for stable doc, it should put copies of docbooks (yes, duplicates) into
svn://svn.kde.org/home/kde/branches/stable/l10n-kde4/documentation/extragear/multimedia/
, and of course POTs into
svn://svn.kde.org/home/kde/branches/stable/l10n-kde4/templates/docmessages/extragear-multimedia/
.

This system implements decoupling from the first paragraph. When a random
app with a random VCS comes along, it just implements Scripty's VCS ops in
that VCS, which would be by that moment well modularized. So maintainers can
play around as they wish (subject only to wider KDE policies, not concerning
translation as such). Translators simply see none of that.

With this the answers to Aarons' four questions become: not important, not
important, all, none. I'm not restating the questions because they are
really not important in this frame. I'd consider it a failure if at any
future moment translators should adapt the workflow not for their internal
reasons, but due to apps' internal business; and likewise in the other
direction, if apps are forced to adapt workflow for translators' internal
organization.

Now, the above is work, and I have no time to actively help. But I do feel
that anything less is just needless strife now and tomorrow, and reduces
flexibility on both sides. Of course, I (and probably Albert, Pino) can
continue answering narrow and precise questions about this and that, as up
till now. It also seems to me, if I've gathered correctly, that Chani with
her current work is going into the above direction, only with less
generality.

The system just as well applies to whatever current apps and modules, until
and if they peel off from central SVN repository. For example, for a current
extragear app the setup would be:

  [kfoobar]
  section = extragear
  subsection = doodles
  vcs = svn
  repo-base = svn://svn.kde.org/home/kde
  ui-stable = branches/extragear/doodles/foobar/2.0/src
  ui-trunk = trunk/extragear/doodles/foobar/src
  doc-stable = branches/extragear/doodles/foobar/2.0/doc
  doc-trunk = trunk/extragear/doodles/foobar/doc

and for a core module:

  [kdegames]
  section = kdegames
  vcs = svn
  repo-base = svn://svn.kde.org/home/kde
  ui-stable = branches/KDE/4.2/kdegames
  ui-trunk = trunk/KDE/kdegames
  doc-stable = branches/KDE/4.2/kdegames/doc
  doc-trunk = trunk/KDE/kdegames/doc

Note 1: Albert has read the above and gave his blessing ("[...] I think this
really makes sense"); I've actually modified the text a bit from what he
read, but nothing substantial.

Note 2: Conceptually, the system as above is already almost up and running
in the neighborhood. Since the beginning of this year, in Gnome they've
introduced a web interface called Vertimus, which checks out Gnome code
(whether controlled by Git or SVN), extracts templates, collects catalogs,
presents them to translators for download, allows upload of translated
catalogs, marking for reviews/acceptance, and whatnot. At this point it only
misses commit capability, but it is planned (until then Gnome translators-
committers have to have those full Git modules around, but they are used to
it anyway). Then they'll have full decoupling such as described above; one
could say Vertimus = Scripty + translators' SVN + higher order terms. Of
course, some Gnome translators are not very happy about having to go through
a web thingy rather than a proper VCS; but these are precisely the internal
matters that should be upon translators to ponder about, and not influence
programmers.

-- 
Chusslove Illich (Часлав Илић)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/kde-scm-interest/attachments/20090526/ca0a8b9b/attachment.sig