On Fri, Jan 20, 2012 at 10:50, Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html