From: Junio C Hamano Date: Fri, 06 Aug 2010 13:30:58 GMT Subject: Re: Cooking of the ab/i18n series Message-ID: <7vmxszamwd.fsf@alter.siamese.dyndns.org> In-Reply-To: Ævar Arnfjörð Bjarmason writes: > On Thu, Aug 5, 2010 at 22:18, Junio C Hamano 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)?