Re: Using Git and separating translations into their own l10n-LL repository

[Simos Xenitellis <simos lists googlemail com>]

On Sat, Jan 17, 2009 at 6:39 PM, Kenneth Nielsen <k nielsen81 gmail com> wrote:
> 2009/1/16 Gil Forcada <gforcada gnome org>:
>>
>> El dv 16 de 01 de 2009 a les 01:42 +0100, en/na Christian Rose va
>> escriure:
>>> On 1/15/09, Claude Paroz <claude 2xlibre net> wrote:
>>> > Le mardi 13 janvier 2009 à 23:01 +0000, Simos Xenitellis a écrit :
>>> >  > This is a long-ish post regarding the migration to Git and
>>> >  > what we can do to make l10n a bit better.
>>> >  >
>>> >  > Here I suggest to use the 'git submodule' support
>>> >  > so that the translation material for each language
>>> >  > reside in a single repository.
>>> >  > Comments would be appreciated.
>>> >  > If all is fine, I'll put this, with more details, to live.gnome.org.
>>> >
>>> > <snip>
>>> >
>>> >  Thanks Simos for taking the time to evaluate such an infrastructure for
>>> >  l10n.
>>> >  However I doubt the relative complexity implied by your solution is
>>> >  worth the trouble. I see basically two use cases:
>>> >
>>> >  1. The non-technical coordinator, who would like the simplest
>>> >  infrastructure to commit his translation files.
>>> >
>>> >  -> In this case, an auto-commit feature integrated in damned-lies is the
>>> >  best solution. No (D)VCS knowledge is required for him. FYI I've already
>>> >  tested a prototype which can do this in the testbed git infrastructure.
>>> >
>>> >
>>> >  2. The geek coordinator who like to have the most control on what he's
>>> >  doing and how he do it.
>>> >
>>> >  -> IMHO, this one won't mind checking out entire git modules. This is
>>> >  not very much different than the current situation.
>>>
>>> FWIW, I fully agree with Claude here.
>>
>> +1 also :)
>
> And a +1 from me.

OK, let's summarize for future reference and close the thread.

One of the issues to try to split translation files from the rest of
the modules is because a 'git clone' downloads the full history of a
repository, compared to a 'svn checkout' which downloads just a
snapshot. In addition, svn can also checkout a subdirectory of a
repository, something that git cannot do.

Separating the repositories in code and translations using 'git
submodule' would add too much effort in terms of updating the tools,
and changing the practices that translators would use to maintain the
translations. It is easier to keep as is.

In terms of disk space, a 'git clone' is surprisingly very economic,
almost matching an 'svn checkout'.
In terms of speed when cloning a repository, git is more CPU intensive
for the GIT server, and is slower than a 'svn checkout'.
It would make sense for translators to dedicate some space so that
cloned repositories are kept locally (instead of erasing them).

Simos