Subject: Re: Has anyone looked at Gettext support for Git itself?

From: Jan Hudec <[email-masked]>
Date: Sat, 22 May 2010 13:01:58 +0200

On Tue, May 18, 2010 at 14:33:31 +0100, Will Palmer wrote:
> On Tue, 2010-05-18 at 11:35 +0200, Thomas Singer wrote:
> > ... and even worse, (s)he will most likely
> > not be able to find a solution by searching google for this error message.
> 
> Other software projects make this a non-issue by reporting an "error
> code" or something along those lines, along with the message. The code
> is easily indexed, so that the message can be located by support staff
> and, nowadays, google. I assume any internationalization effort would
> require a message code of some sort be generated internally (if only to
> look up which internationalized message to display), so doing something
> as simple as outputting the internally-used code (even if that is just a
> hash of the English version of the message) could solve this problem.

Gettext does not require any kind of internal ID. It uses the english string
as a key. It should (as already suggested) be easy to have
a reverse-translation tool on the web somewhere for deciphering session logs
from users with non-english locale.

Non-English-speaking users won't be able to find a solution to problem by
searching google most of the time anyway, though, because the prevalent
English resources won't be understandable for them. Usually, however, they
will have somebody on their team who does and will be able to help them out
if they get into deep trouble.

> Having error messages pasted into #git in 14 different languages could
> be annoying, but if those are 14 people who otherwise would not be using
> git at all, then I expect we're looking at the wrong problem, and
> internationalisation /should/ be a priority.
> 
> But what do I know? I speak English :)

It is important for cases when somebody wants to use git in their team, but
some of their colleagues don't speak English. One has to expect having to
help their colleagues occasionally in such cases, but than when you propose
using git in some team, you have to expect having to help your colleagues
in any case.

-- 
						 Jan 'Bulb' Hudec <[email-masked]>