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

Ævar Arnfjörð Bjarmason [off-list ref] writes:

On Wed, Jan 18, 2012 at 19:57, Alex Riesen [off-list ref] wrote:
...

quoted

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.

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.

Now I haven't done exhaustive tests but this is the sort of slowdown
we might be looking at on Linux for output,...

I think we judged that it is OK not to worry about the performance of
message generation, back when we decided to take the current approach.

Anyway speed is the least of the issues here, it's not like we're very
constrained by spewing out gettext output.

I just think we should consider portability more carefully than "it
doesn't work on one obscure setup, let's change it everywhere", when
actually it's working just fine in most places.
...
But in summary: We shouldn't be *always* using fallback functions
whether they're the C stuff in compat/* or the gettext fallbacks in
git-sh-i18n.sh just because there's some version out there of the
system-supplied functions that's broken.

It makes sense to prefer the system functions by default in both
cases, but when the OS one can be broken or lacking we can just add
probes or Makefile options like we do for fnmatch() with the
NO_FNMATCH_CASEFOLD switch.

So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
that correct?

If that is the case, should we do something like

	LANG=C LC_ALL=C
        export LANG LC_ALL

in our shell scripts, when building for NO_GETTEXT target?

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

Ævar Arnfjörð Bjarmason [off-list ref] writes:

quoted

On Wed, Jan 18, 2012 at 19:57, Alex Riesen [off-list ref] wrote:
...

quoted

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

On Thu, Jan 19, 2012 at 01:17, Junio C Hamano [off-list ref] wrote:

So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
that correct?

I think yes.

If that is the case, should we do something like

       LANG=C LC_ALL=C
       export LANG LC_ALL

in our shell scripts, when building for NO_GETTEXT target?

Just for the record: gettext here stays broken with LANG and LC_ALL set to C.
But the locale-dependent formatting in C functions will change. Wont be a
problem here, though. The named formatting is broken, too: strftime, for
instance, always formats in C locale.