Re: Gettext solution (Was: Re: gettext packages)

[Julian Gilbey <J.D.Gilbey@qmw.ac.uk>]

> What I meant was I've never got it to transform an english string into
> something else, even when gettext works on the same string, e.g.:
> 
> bash$ LANG=de TEXTDOMAIN=gnome-libs gettext -s Exit
> Beenden
> bash$ LANG=de TEXTDOMAIN=gnome-libs echo $"Exit"
> Exit

For some reason which I haven't yet figured, bash requires the
LANG/LC_* variable to be exported before it will perform locale
translation.  I don't know why, but this would be the normal state of
affairs when using NLS.  (You would have to have exported one of the
language variables for it to even reach your script.)

So the following works:

bash$ export LANG=de
bash$ TEXTDOMAIN=gnome-libs
bash$ echo $"Exit"
Datei/Beenden

Note also that $"..." substitution happens very early in the
parsing, long before the TEXTDOMAIN assignment is performed, so that
the LANG and TEXTDOMAIN variables would be set too late in your
one-line $"..." command, whereas they are passed as environment
variables to the gettext invocation.

Think about the context: a script would be called with the appropriate
LANG/LC_* environment variables set.  The script would begin with a
line like:

TEXTDOMAIN=foobar

Then the l10n will work for the rest of the script.

> In fact, I wrote a script to try this and ltrace shows a correct call
> to textdomain() but no call to gettext()...

Haven't checked, but I assume that gettext() wouldn't be called unless
the locale was other than C or POSIX.

> > if command -v gettext >/dev/null 2>&1; then echo="gettext -s"
> > elif [ -n "$BASH" ]; then xecho(){ eval "echo \$\"$*\""; } ; echo=xecho
> > else echo=echo
> > fi
> > 
> > and then use $echo instead of echo throughout the script.
> 
> I don't think there's much in it, and script maintainers can of course
> use whichever method they wish, provided it works.

Yes, you are right.

> > But of course, if the script is #!/bin/bash, $"..." can be used in the
> > first place.  And if it's /bin/sh, then I don't know whether it's
> > necessarily so useful to test for sh=bash.
> 
> IMHO, #!/bin/bash is evil and should be avoided. Arguably, since bash
> is an essential package in Debian, it's not fatal, but I'm just not
> happy about it.

Fair enough.  So let's find a better solution to the gettext version.
There is an advantage to the bash version though: if there is a lot of
output for the user, it saves calling an external gettext program on
every occasion on which a message is output.

> It's possible that the script is /bin/sh and /bin/sh is a symlink to
> bash, and that the gettext program is uninstalled. In fact, won't this
> be the default state of a non-developer Debian installation? In this
> case, the $"..." method should still be usable, allowing i18n of shell
> scripts without requiring us to split packages or change default
> setups.

Yes, at least for the time being.  But just because it's the default
doesn't necessarily mean that it's the Right Thing.  I have advanced a
gradually developing argument for splitting the gettext package.

> > secure version of the mktex* scripts), I intend to help the upstream
> > author split out the gettext program from the rest of the suite.
> 
> Which I think would be handy, since bash's locale translation doesn't
> seem to work for me...

Try the above ;)

   Julian

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

  Julian Gilbey, Dept of Maths, QMW, Univ. of London. J.D.Gilbey@qmw.ac.uk
        Debian GNU/Linux Developer,  see http://www.debian.org/~jdg