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

From: Jan Hudec <bulb@ucw.cz>
Date: May 22, 2010, 11:01 UTC
Message-ID: <20100522110158.GA30035@efreet.light.src>
In-Reply-To: <1274189611.1294.10.camel@wpalmer.simply-domain>

On Tue, May 18, 2010 at 14:33:31 +0100, Will Palmer wrote:

Show 12 quoted lines

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

Show 6 quoted lines

> 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 <bulb@ucw.cz>