Junio C Hamano writes:
> Junio C Hamano writes:
>
>>> Oh, I forgot that we actually had a wrapper instead of the usual _.
>>> Yes, I think that would be the better solution to guard against this.
>>
>> OK, then let's replace the patch text of your commit ;-).
>
> He, we need to update the log me
Junio C Hamano writes:
>> Oh, I forgot that we actually had a wrapper instead of the usual _.
>> Yes, I think that would be the better solution to guard against this.
>
> OK, then let's replace the patch text of your commit ;-).
He, we need to update the log message a bit, too.
-- >8 --
From: T
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> The gettext .po files have a header, but it looks like the translation
>>> specification for an empty string. This results in _("") actually
>>> returning that header.
>>
>> Thanks; this is a tricky bit to catch and m
Junio C Hamano writes:
> Thomas Rast writes:
>
>> The gettext .po files have a header, but it looks like the translation
>> specification for an empty string. This results in _("") actually
>> returning that header.
>
> Thanks; this is a tricky bit to catch and makes me wonder where else
> we h
Thomas Rast writes:
> The gettext .po files have a header, but it looks like the translation
> specification for an empty string. This results in _("") actually
> returning that header.
>
> Prevent parseopt from passing empty strings to gettext when it
> displays help about commands. In some in
The gettext .po files have a header, but it looks like the translation
specification for an empty string. This results in _("") actually
returning that header.
Prevent parseopt from passing empty strings to gettext when it
displays help about commands. In some instances it already did this,
but
6 matches
Mail list logo
