On Fri, Aug 6, 2010 at 13:30, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Æ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 was thinking about support from the core contributors, which'd have
to deal with gettext in the long term in one way or another.
> 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.
I'm also worried about that, and I have some plans to deal with it
after the merge.
The first and most obvious one is that the list will be reviewing
gettexizing patches as they go through. A patch which changes some
plumbing format would be called out, but not one that just changes the
UI messsage of e.g. "git init".
There's also more that can be done, e.g. altering the test-lib.sh so
that you can set an environment variable that causes it not to reset
LC_ALL to C. Then run the tests and see if anything breaks.
I was going to run a smoker with that setup on some of the major
languages if gettext and smoke support was accepted.
>> 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)?
We'd get this sort of list out of "TRANSLATORS:" comments for
free. They're automatically extracted and presented to translators and
others with the xgettext program.
Maintaining a list of messages in Documentation/ somewhere that's
bound to get out of date with the source code doesn't make sense given
the TRANSLATORS support.
--
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