Subject: Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined

From: Johannes Sixt <[email-masked]>
Date: Thu, 19 Jan 2012 08:13:24 +0100

Am 1/19/2012 1:17, schrieb Junio C Hamano:
> Ævar Arnfjörð Bjarmason <[email-masked]> writes:
> 
>> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <[email-masked]> wrote:
>> ...
>>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>>> whether it works, or not.
>>
>> That's not what NO_GETTEXT means, and not what it *should* mean. It
>> means that your output won't be translated, but we might still make
>> use of a locally installed library to provide the gettext() and
>> eval_gettext() functions.
> 
> You are right.

Sorry to disagree: We have, e.g., NO_MMAP, and I can set it to request
that some alternative is used, even if I have a working mmap(). The option
name "NO_GETTEXT" is in exactly the same spirit.

> In the current approach we take for shell scripts, we cannot have "No i18n
> whatsoever and messages are emit with printf and echo". We always have to
> go through gettext/eval_gettext even though they may be an implementation
> that does not do i18n at all.

Just like we go through _() in C code, even though there may be an
implementation that does not do i18n at all, right?

gettext/eval_gettext annotations are the shell equivalent of _()
annotations in C code, aren't they? Neither go away just by defining
NO_GETTEXT. It is just a quality-of-implementation issue that those
annotations have as little overhead as possible if NO_GETTEXT is defined.
In C, it is easy, in shell code it may be more involved.

-- Hannes