Johannes Sixt [off-list ref] writes:
... 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.
quoted
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?
Yes, just like that. The small detail that _() can be #define'd out to
empty while gettext/eval_gettext cannot be made to be no-impact like that
does not really matter.
In C, it is easy, in shell code it may be more involved.
Correct.
On Thu, Jan 19, 2012 at 19:30, Junio C Hamano [off-list ref] wrote:
Johannes Sixt [off-list ref] writes:
quoted
... 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.
quoted
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?
Yes, just like that. The small detail that _() can be #define'd out to
empty while gettext/eval_gettext cannot be made to be no-impact like that
does not really matter.
quoted
In C, it is easy, in shell code it may be more involved.
Correct.
To elaborate, the C code can:
* Use the system gettext library to get translations.
* Use the system gettext library, but effectively be pass-through
because the user has the C locale.
* Use our fallback functions which in any modern compiler will be
optimized out.
However with the shell code we can:
1. Be using the system gettext & eval_gettext to get translations.
2. Be using the system gettext & eval_gettext as pass-through, either
because we don't have translations since we've installed with
NO_GETTEXT=YesPlease, or because we're in the C locale.
3. Haven't detected that gettext.sh etc. exists, so we have to provide
our own fallbacks.
The proposed patch would move all users of NO_GETTEXT=YesPlease to #3,
even though on most platforms we don't need to define our own dummy
fallbacks since the system already provides them.
I don't particularly like it because I'd rather use the OS vendor's
implementation if possible, even for fallback.
However it being broken is also unacceptable, but I think the way
forward is to detect the breakage either at compile time or at
runtime, to that end Alex could you provide us with the output from
the following commands on the offending system where this is broken:
$ type gettext.sh
$ gettext.sh --version
$ gettext -h
$ gettext "some test text"
$ . gettext.sh
eval_gettext
$ variable=value eval_gettext "some \$variable"
Then how the eval_gettext function is defined:
$ type eval_gettext
eval_gettext is a function
eval_gettext ()
{
gettext "$1" | ( export PATH `envsubst --variables "$1"`;
envsubst "$1" )
}
And then a --version for whatever programs that function uses,
e.g. here:
$ envsubst --version
Once we know how it breaks we can e.g. add configure tests for
checking whether we can use the system's gettext library for the
fallbacks.
Could you also run the git test suite as described in t/README? I'd
expect a lot of the i18n tests to fail, but it would be curious to see
which ones exactly.
On Fri, Jan 20, 2012 at 10:50, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
However with the shell code we can:
1. Be using the system gettext & eval_gettext to get translations.
2. Be using the system gettext & eval_gettext as pass-through, either
because we don't have translations since we've installed with
NO_GETTEXT=YesPlease, or because we're in the C locale.
3. Haven't detected that gettext.sh etc. exists, so we have to provide
our own fallbacks.
The proposed patch would move all users of NO_GETTEXT=YesPlease to #3,
even though on most platforms we don't need to define our own dummy
fallbacks since the system already provides them.
I don't particularly like it because I'd rather use the OS vendor's
implementation if possible, even for fallback.
Well, I dunno. I wouldn't trust anything to this particular "OS vendoer".
However it being broken is also unacceptable, but I think the way
forward is to detect the breakage either at compile time or at
runtime, ...
Better at runtime, unless the packager explicitly stated they don't want
any of this.
... to that end Alex could you provide us with the output from
the following commands on the offending system where this is broken:
$ type gettext.sh
gettext.sh is /usr/bin/gettext.sh
$ gettext.sh --version
/usr/bin/gettext.sh (GNU gettext-runtime) 0.18.1
Copyright (C) 2003-2007 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Bruno Haible
$ gettext -h
Nothing. Exit code 127.
$ gettext "some test text"
Nothing. Exit code 127.
$ . gettext.sh
Nothing. Exit code 0.
eval_gettext
Nothing. Exit code 127.
$ variable=value eval_gettext "some \$variable"
Nothing. Exit code 127.
Then how the eval_gettext function is defined:
$ type eval_gettext
eval_gettext is a function
eval_gettext ()
{
gettext "$1" | ( export PATH `envsubst --variables "$1"`;
envsubst "$1" )
}
And then a --version for whatever programs that function uses,
e.g. here:
$ envsubst --version
Nothing. Exit code 127.
Once we know how it breaks we can e.g. add configure tests for
checking whether we can use the system's gettext library for the
fallbacks.
The exit code seems to be a good enough test here, but testing some
output (or even translation) would be safer.
I believe gettext (the binary) just doesn't start at all here. Maybe
some Cygwin library wrong or missing library. Happens all the time
here, as we have different Cygwin installations depending on the
currently used toolchain. QNX Momentics, in particular. Different
versions of them, and it is too cumbersome to keep them apart.
Could you also run the git test suite as described in t/README? I'd
expect a lot of the i18n tests to fail, but it would be curious to see
which ones exactly.
Yes, they do. Can't run them on this problematic system, because they
tend to crash it, if run for an undetermined while. On the other system,
which can run them, gettext works (it is an older Cygwin installation),
so almost all tests pass (some still don't, but for reasons unrelated).
Strangely enough, the problematic system can build. So I don't copy
the git binaries, they are actually built on that system.
Even though we can load gettext.sh the gettext(1) and eval_gettext
functions it provides might be completely broken. This reportedly
happens on some Cygwin installations where we can load gettext.sh, but
gettext and eval_gettext both return exit code 127 and no output.
The reason we're trying to load gettext.sh (or the equivalent Solaris
implementation) at all is so we don't have to provide our own fallback
implementation if the OS already has one installed, but because we
didn't test whether it actually worked under GNU gettext we might end
up with broken functions.
Change the detection in git-sh-i18n so that it tests that the output
of "gettext test" produces "test", on Solaris we already test that
"gettext -h" produces "-h", so we were already guarded against the
same sort of failure there.
Reported-by: Alex Riesen <redacted>
---
Here's a minimal patch to git-sh-i18n that should make things work on
Cygwin and any other platforms with broken gettext functions while
also using the OS-provided functions if they work.
I've added a new t0201-gettext-fallbacks-broken-gettext.sh test that
tests this. This required a small change in lib-gettext.sh so I
wouldn't load test-lib.sh twice.
Note that there's already a t0201* test in the repo. Maybe we want to
increment all the gettext test numbers by one to make room for it?
As an aside I'm really not a big fan of having hardcoded numbers in
the test files like this. We don't care about the order of execution
here.
git-sh-i18n.sh | 2 +-
t/lib-gettext.sh | 7 +++++-
t/t0201-gettext-fallbacks-broken-gettext.sh | 28 +++++++++++++++++++++++++++
3 files changed, 35 insertions(+), 2 deletions(-)
create mode 100755 t/t0201-gettext-fallbacks-broken-gettext.sh
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index b4575fb..26a57b0 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -18,7 +18,7 @@ export TEXTDOMAINDIR
if test -z "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1
+ if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1 && test "$(gettext test 2>&1)" = "test"
then
# This is GNU libintl's gettext.sh, we don't need to do anything
# else than setting up the environment and loading gettext.sh
diff --git a/t/lib-gettext.sh b/t/lib-gettext.sh
index 0f76f6c..2c5b758 100644
--- a/t/lib-gettext.sh
+++ b/t/lib-gettext.sh
@@ -3,7 +3,12 @@
# Copyright (c) 2010 Ævar Arnfjörð Bjarmason
#
-. ./test-lib.sh
+if test -z "$TEST_DIRECTORY"
+then
+ # In case the test loaded test-lib.sh by itself to do some tests
+ # prior to loading us.
+ . ./test-lib.sh
+fi
GIT_TEXTDOMAINDIR="$GIT_BUILD_DIR/po/build/locale"
GIT_PO_PATH="$GIT_BUILD_DIR/po"
diff --git a/t/t0201-gettext-fallbacks-broken-gettext.sh b/t/t0201-gettext-fallbacks-broken-gettext.sh
new file mode 100755
index 0000000..92b95ae
--- /dev/null
+++ b/t/t0201-gettext-fallbacks-broken-gettext.sh
@@ -0,0 +1,28 @@
+#!/bin/sh
+#
+# Copyright (c) 2012 Ævar Arnfjörð Bjarmason
+#
+
+test_description='Gettext Shell fallbacks with broken gettext'
+
+. ./test-lib.sh
+
+test_expect_success 'set up a fake broken gettext(1)' '
+ cat >gettext <<-\EOF &&
+ #!/bin/sh
+ exit 1
+ EOF
+ chmod +x gettext &&
+ ! ./gettext
+'
+
+PATH=.:$PATH
+. "$TEST_DIRECTORY"/lib-gettext.sh
+
+test_expect_success C_LOCALE_OUTPUT '$GIT_INTERNAL_GETTEXT_SH_SCHEME" is fallthrough with broken gettext(1)' '
+ echo fallthrough >expect &&
+ echo $GIT_INTERNAL_GETTEXT_SH_SCHEME >actual &&
+ test_cmp expect actual
+'
+
+test_done
--
1.7.7.3
On Fri, Jan 20, 2012 at 13:49, Ævar Arnfjörð Bjarmason [off-list ref] wrote:
Even though we can load gettext.sh the gettext(1) and eval_gettext
functions it provides might be completely broken. This reportedly
happens on some Cygwin installations where we can load gettext.sh, but
gettext and eval_gettext both return exit code 127 and no output.
The reason we're trying to load gettext.sh (or the equivalent Solaris
implementation) at all is so we don't have to provide our own fallback
implementation if the OS already has one installed, but because we
didn't test whether it actually worked under GNU gettext we might end
up with broken functions.
Change the detection in git-sh-i18n so that it tests that the output
of "gettext test" produces "test", on Solaris we already test that
"gettext -h" produces "-h", so we were already guarded against the
same sort of failure there.
Reported-by: Alex Riesen <redacted>
---
Here's a minimal patch to git-sh-i18n that should make things work on
Cygwin and any other platforms with broken gettext functions while
also using the OS-provided functions if they work.
FWIW, I confirm it works (which is quite obvious).
Just for giggles, I even risked running the tests and, of course, crashed
that piece of junk with broken Cygwin installation.
Please don't ask me to do that again :) restarting it is PITA as well.
Just for future reference to all poor Cygwin users:
I also left NO_GETTEXT in the config.mak. This, BTW, explains why git
works, while gettext binary does not: one .dll dependency less.