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

[Ian Monroe]

2009/5/26 Chusslove Illich <caslav.ilic at gmx.net>:
> 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.

I agree that there's no reason translators and programmers should use
the same system. However I don't think letting individual projects in
KDE pick their own VCS is a good idea. Amarok is probably going to
switch before the rest, but this is purely transitional. Keeping all
the developers in KDE on the same technological ship is important to
the culture, and there's no technology more critical to development
then VCS.

> 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

Outside of the "vcs = git" line (since this should be assumed IMO) the
above makes a lot of sense to me.

We are going to have to have some way for project maintainers to
specify which branches should be translated.

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

The above paragraph is basically what Chani has done, though I'm
guessing she hasn't tackled multiple branches per app yet.

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

I have no clue about what to do with docs. :) Currently they are
completely separate from Amarok so we don't have to tackle the issue
immediately. (One bonus of Amarok switching first is that we can phase
in needed solutions like that one-by-one).

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

Something like this would make sense. The tarball scripts could just
download the translations from Vertimus rather then commit them to Git
at all. But this is a decision for kde-i18n-doc, not this list. :)

Ian