From: Johannes Sixt Date: Thu, 19 Jan 2012 07:13:24 GMT Subject: Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined 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: > Ævar Arnfjörð Bjarmason writes: > >> On Wed, Jan 18, 2012 at 19:57, Alex Riesen 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