Re: Using Transifex in git.git

From: Michael Witten <mfwitten@gmail.com>
Date: Jun 15, 2011, 13:45 UTC
Message-ID: <BANLkTikkOMmp869q8x4c8PPe1AGKP4+Qfw@mail.gmail.com>
In-Reply-To: <BANLkTin9bhtB_OPMWCVsbtKBpRXp2o=uLA@mail.gmail.com>

On Wed, Jun 15, 2011 at 13:21, Erik Faye-Lund <kusmabite@gmail.com> wrote:

Show 16 quoted lines

> On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> I think it's a good idea to use a system like Transifex to manage
>> translations for git.git, so that we can attract a large number of
>> non-technical translators.
>
> Are we sure we want non-technical translators to translate Git, a
> highly technical program with many technical terms?
>
> I'm guessing that Git probably should be translated by it's users,
> because we have a lot of Git-jargon that is difficult for people who
> doesn't know Git to translate. But perhaps an initial translation for
> each language is enough to establish a language-specific translation
> of all Git-jargon, and then afterwards we can get help from
> non-technical people to improve the language? I'm just asking, I don't
> know how Transifex works at all...

I think your second paragraph ALMOST has the right of it.

Open source showed us the virtue of "Release early and release often"; it's best to get people using something even if it's crap at first, especially because people can then figure out what needs to be bettered.

Wikipedia showed us that if we reduce the requirements to contribution (which, if you think about it, also means that backwards compatibility must be largely forgone), then the net result is a constantly and rapidly improving product (albeit with minor but inconsequential setbacks due to fools and miscreants).

So, who cares if the translation for the Nǁngǃke language (look it up) is initially junk at first; if it's easy to fix, then it will rapidly improve into a steady state of high quality.