Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> On Thu, Aug 5, 2010 at 22:18, Junio C Hamano <gitster@xxxxxxxxx> 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)?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html