Using Transifex in git.git

Using Transifex in git.git

[Ramkumar Ramachandra]

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

Re: Using Transifex in git.git

[Andreas Ericsson]

On 06/14/2011 07:57 AM, Ramkumar Ramachandra 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.
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Using Transifex in git.git

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra <artagnon@gmail.com> 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.
"""

Re: Using Transifex in git.git

[Ramkumar Ramachandra]

Hi Andreas,

Andreas Ericsson writes:
> 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.

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

Re: Using Transifex in git.git

[Ramkumar Ramachandra]

Hi Ævar,

Ævar Arnfjörð Bjarmason writes:
>  * I don't want people to *have* to use any one interface.
>  * Any way of editing the translations will have to comply with git's
>  normal patch submission process.

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

Re: Using Transifex in git.git

[Andreas Ericsson]

On 06/14/2011 11:37 AM, Ævar Arnfjörð Bjarmason wrote:
> On Tue, Jun 14, 2011 at 07:57, Ramkumar Ramachandra<artagnon@gmail.com>  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:
> 
>   * 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.
> 

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Using Transifex in git.git

[Ramkumar Ramachandra]

Hi Andreas,

Andreas Ericsson writes:
> 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.

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

Re: Using Transifex in git.git

[Andreas Ericsson]

On 06/15/2011 09:33 AM, Ramkumar Ramachandra wrote:
> Hi Andreas,
> 
> Andreas Ericsson writes:
>> 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.
> 
> Fair point.  How do we work around this?
> 1. Can we relax the requirements for contributing translations?  To what extent?

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.

> 2. It think one commit per edit-session per language sounds sane.

Yup.

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

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.

-- 
Andreas Ericsson                   andreas.ericsson@op5.se
OP5 AB                             www.op5.se
Tel: +46 8-230225                  Fax: +46 8-230231

Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.

Re: Using Transifex in git.git

[Ramkumar Ramachandra]

Hi again,

Andreas Ericsson writes:
> 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.

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

Re: Using Transifex in git.git

[Erik Faye-Lund]

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

Re: Using Transifex in git.git

[Michael Witten]

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

Re: Using Transifex in git.git

[Ævar Arnfjörð Bjarmason]

On Tue, Jun 14, 2011 at 14:07, Andreas Ericsson <ae@op5.se> 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.

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.

Re: Using Transifex in git.git

[Ævar Arnfjörð Bjarmason]

On Wed, Jun 15, 2011 at 15:21, Erik Faye-Lund <kusmabite@gmail.com> wrote:
> 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?

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.

Re: Using Transifex in git.git

[Ævar Arnfjörð Bjarmason]

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.

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

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.