Re: Using Transifex in git.git

On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra [off-list ref] wrote:

Hi Dimitris et al,

[+CC: Git List; for wider exposure]
[+CC: Jonathan Nieder; he has been involved with translations in the past]
[+CC: Junio C Hamano; for authoritative policy advice]

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.  Further, I think it's a good time to start
off on this now, since many of the i18n bits from Ævar's series are in
'master'.  So, I'm looking to start off a discussion about how to
adapt a translation system into our current patch workflow.  Dimitris
is the lead developer of Transifex, and can help with the details.

Turns out I have two E-Mails related to this in my inbox. Below
follows the reply I sent to the other one in private mail, but applies
here too:

"""
Sorry, I didn't have time to look at this at the time. I think it's
really interesting, having translations be easier to manage is
definitely something we want so that mortals can contribute
translations to git.

I hadn't followed up on this because git.git still doesn't have
strings marked up for translation. We have the C bits of that, but the
patch series for the shellscripts is still in flight.

After that I was going to submit some more patches to add the initial
po/*.po files, after which I think considering having a web interface
like this would make sense.

Here's a couple of things though:

 * I don't want people to *have* to use any one interface.

 As far as I'm concerned the canonical way to submit translations is
 just to check out git.git's master branch, run "make pot", and then
 submit a patch for a PO file to the list.

 Of course we can *also* support doing that through a web UI, the web
 UI is after all just a fancy way of replacing your $EDITOR. But I
 don't think we should be tied to any one UI. I.e. people should be
 able to take git.pot and edit it everywhere, and a web UI like
 Transifex can't assume that it e.g. won't have to resolve conflicts
 because something changed upstream.

 * Any way of editing the translations will have to comply with git's
  normal patch submission process.

  When you normally submit a patch to Git you have to write a
  sensible commit message for it, change one logical thing at a time,
  and you have to agree to the contributor's agreement by adding a
  Signed-off-by to your Git commit.

  I think this will probably clash head-on with how any web
  translation UI with its own user accounts, no way to enter commit
  messages etc. will work.
"""