Using Transifex in git.git

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.

Thanks.

-- Ram

On 06/14/2011 07:57 AM, Ramkumar Ramachandra wrote:

It's always better to start coding on changes and then show how those changes make life easier for people than to suggest something out of thin air and start a discussion about it before applying any work.

I for one have no idea what transifex is, how it works or why it's superior to any of the currently existing tools to manage .po files. I also have no real interest in translations, although I chip in a bit with the swedish one when someone else does the grunt part of the work to make it happen. I believe many here share that sentiment with me, so you'd probably be better off doing a sales-pitch kind of mail to the people who have contributed greatly to the actual translations earlier so they can voice their opinions on what system they want to use.

Hi Andreas,

Andreas Ericsson writes:

Yes, this would normally be the case. My apologies for being unclear about the purpose of the original email: It's not a sales pitch where I'm trying to sell one translation system - I'm merely trying to find out what features the community at large would like from an abstract web-based translation engine; what should it look like so that it fits into our current patch/ review system? What this translates to in terms of work: evaluation various translation systems, and writing the necessary features into the one that comes closest to what we want. At a glance, Transifex seems to be a good option, but I could easily be wrong about that.

-- Ram

On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

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

Hi Ævar,

Ævar Arnfjörð Bjarmason writes:

Thanks for the detailed response.  The way I see it, major changes are
required in two distinct areas:
1. The way the user interacts with the web-based UI.  In the current
UI (of Transifex), everything is one continuous stream; everything is
auto-saved, and the user makes no indication of a logical change.
This has to be changed to enforce creation of commit messages for the
Git project: without a valid commit message and signoff, the
translations are essentially useless.  Also, authorship information
isn't available -- so, the user accounts should have a way to keep
this information, and the Git project should be able to demand that
this information is available.
2. The way the system stores the various versions of the translation
information, and gives it back to the individual projects.  Some
projects might like the continuous stream to be squashed into one
commit that says something like "Sync translations with Transifex"
like it does current, some might like a Subversion dumpstream, while
others like the Git project might like a fast-import stream. When we
get the stream, we should be able to import it, rebase the commits as
necessary, and throw away the commits that we don't like before
integrating it.

I'll start mocking up a solution. Are there some issues that I haven't covered yet?

-- Ram

On 06/14/2011 11:37 AM, Ævar Arnfjörð Bjarmason wrote:

Historically, a translation for one language has been considered "one logical change" in that respect. I think it's safe to assume that if we want translators to stick around they shouldn't need to divide their changes on a per-message or per-command basis. Especially since such divisions wouldn't be very easy to do if all you've got to go on is a pot-file.

Hi Andreas,

Andreas Ericsson writes:

Fair point.  How do we work around this?
1. Can we relax the requirements for contributing translations?  To what extent?
2. It think one commit per edit-session per language sounds sane.  If
people just go around translating some random strings that they like
(which is often the case), what is the sense in asking them to write a
commit message? Maybe we can write one ourselves before committing it,
provided they signoff on all the commits? Maybe there should be an
auto-signoff option too?

-- Ram

On 06/15/2011 09:33 AM, Ramkumar Ramachandra wrote:

Probably at least a bit. It doesn't affect core functionality in any way so it's unlikely it will cause bugs that requires deep diving in the history, so changes needn't be so isolated and commit messages are less important than for code changes.

Yup.

No and no. No auto-signoff, and no auto-message. That will just leave us with a long string of auto-signoffs and automatic messages, and that's horrible.

The "no auto-signoff" rule is from Junio btw, and I doubt he's changed his mind regarding that. The "no auto-message" is just my gut feeling that everyone will really hate to see changes without an explanation. Something simple like "5 out of 6 of the large scm's (in terms of userbase) uses 'blarg' instead of 'fnurg' for commits, so let's call it that in our examplinitian translation too" is enough and will be quite helpful when it comes to explaining why a change is made.

Otoh, "Updated translations for new release" will probably be the most common message, and that's fine too if that's what happened.

Hi again,

Andreas Ericsson writes:

1. Auto signoffs: Do you want translators to explicitly type out s-o-b
message after contributing a few translations?! I think it's fair to
assume that many of us use auto-signoffs as well -- I personally have
format.signoff set to true, but I've read SubmittingPatches.  I don't
propose to have a blind auto signoff, but translators can atleast be
forced to read the agreement and hit "Yes, I want to auto signoff all
my contributions".
2. Auto commit messages: Er, what I meant: the translation coordinator
has to clean up the history and fill in the commit messages before she
tries to get the new translations merged into git.git. The lazy
translators have the option of leaving it empty.

One quick query: Let's say there are 10 tiny commits modifying the same line in the same language, and the translation coordinator wants to squash these into one. Is it alright to have the authorship info point to the coordinator, with the commit message crediting all 10 individual translators?

-- Ram

On Tue, Jun 14, 2011 at 14:07, Andreas Ericsson <ae@op5.se> wrote:

Then again, our policy with patches to the C code is that you should make make changes in small logical chunks with good commit messages, so that the people that come after you can make sense of what you did.

Translations are similar, why you chose to translate certain terms in certain ways could (and IMO should) be explained in commit messages.

I don't think it should be a per-command or per-message basis, just something like:

 * commit 1: start a XX.po file
 * commit 2: translate the word "branch", and explain why you picked
   that particular translation.
 * Translate similar messages etc.

Or do the whole thing in one big commit, but have a commit message that explains the choice of translations.

On Tue, Jun 14, 2011 at 11:37, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:

To clarify a bit. I think it'd be great if we can get more translations through any scheme possible.

However, I'd personally prefer if this was delayed a bit until the outstanding po/*.po patches I have have landed in master. I already have those locally ready for submission, I'm just going to submit them after my current series hits master.

The timeline on that is entirely dependent on when Junio merges my patches down.

But that's just my 0.02c. I don't think I own i18n in any way, so if someone wants to set up some web ui, gather PO files, and submit them that's great. More power to them.

Also, I just mentioned this because those are our existing patch submission guidelines, which I thought would be reasonable to assume would be the same in this case. Whether we observe this I think would be something for the maintainer to answer.

Personally I think signed-off-by is silly, and wouldn't mind if we got new translations in one giant commit with a crappy commit message, but I didn't make the rules.

On Tue, Jun 14, 2011 at 7:57 AM, Ramkumar Ramachandra <artagnon@gmail.com> wrote:

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

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

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.

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

Well, usually even bad translations (although not horribly bad) are better than nothing.

Most translated strings will have little or nothing git-specific about them, but will be something like "We couldn't open file %s due to XYZ".

And even if someone translates e.g. "branch" incorrectly they usually do so consistently, so it's easy to search & replace those sort of issues out of existence.