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

From: Johannes Sixt <j.sixt@viscovery.net>
Date: Jan 19, 2012, 07:13 UTC
Message-ID: <4F17C294.6010004@viscovery.net>
In-Reply-To: <7vfwfclf4v.fsf@alter.siamese.dyndns.org>

Am 1/19/2012 1:17, schrieb Junio C Hamano:

Show 13 quoted lines

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> 
>> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> 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