Re: Cooking of the ab/i18n series

From: Junio C Hamano <gitster@pobox.com>
Date: Aug 6, 2010, 13:30 UTC
Message-ID: <7vmxszamwd.fsf@alter.siamese.dyndns.org>
In-Reply-To: <AANLkTim1G=wjAgts_BvjwU8_B1wqrUEQHWbP_MY=cJa9@mail.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

Show 10 quoted lines

> On Thu, Aug 5, 2010 at 22:18, Junio C Hamano <gitster@pobox.com> wrote:
>>
>> When people see the benefit of doing so.  I currently do not see much need
>> for it myself but I am a minority ;-).
>
> That's news to me. I'd assumed that it was mostly on track, i.e. that
> it would get merged down after cooking for a while in pu.
>
> However, if it's a matter of gathering popular support maybe I should
> change my strategy a bit.

The "popular support" needs to be qualified. If you ask any random person "Is it a good thing if software package X supports i18n?", the answer would always be "yes"; popular support in that sense doesn't mean much.

I am more worried about unintended consequence of this particular execution. For example, I would want to be absolutely sure that we won't break plumbing output in 'next' and the proposed mechanism helps others avoid breaking things by mistake.

> The follow-up work I was referring to was the project we'll need to
> undertake once it's merged to convert "foo" to _("foo") as
> appropriate.

That is one good example. Perhaps we can get a list of messages that we can place in Documentation/ area (e.g. "'Not up-to-date' - this message is given when you have local changes in a file in the working tree; given by command X, Y and Z") out of that effort for free? Perhaps such a list can help us verify that i18n does not break plumbing output (because the list does not contain plumbing messages)?