Dealing with gettext.sh
Writing a Shell software that uses gettext is not really common, and writing it for a Debian environment requires the sofwtare to be able to run without gettext, as woody’s gettext-base package does not provide /usr/bin/gettext.sh.
Here is a hint about that, coming from the backup-manager’s code.
The tricky thing to do is to wrap the gettext API in order to first find if the library is there. We would then have a custom gettext.sh library that would just do the switch between two libs: a real one and a fake one. Both libraries provide the same function called translate(). The real function would use gettext as expected, whereas the fake one would just echo the string.
Things become less obvious when you want to use eval_gettext() which provides translation for strings with variables. Strings should then be pure static, without $foo inside but \$foo instead.
The real translate() function would look like that:
. /usr/bin/gettext.sh
export TEXTDOMAIN="myprogram"
translate()
{
eval_gettext "$1"; echo
}
Our dummy translate() function should then be able to render a static string with $foo occurences by their real values, in order to behave the same as the real one:
translate()
{
out=$(echo "$1" | sed -e 's/\$/$/g')
out=$(eval "echo "$out"")
echo "$out"
}
When this is done, it just remains to use translate() everywhere we want to echo a string in the software. This works pretty well and allows the software to run properly - but untranslated - on woody.
Moreover, as there is a bug report (#284637) on the fact that /usr/bin/gettext.sh is located under /usr/bin and is not executable, the gettext.sh library might move in the future.
This way of programming gettext in a Shell script could avoid the software to crash when gettext-base gets updated.
Recent Comments