[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: bashisms and i18n



On Tue, 25 Aug 1998, Michael Sobolev wrote:

> Now, when I know how to write localized scripts for bash, I am not sure that
> it is a good idea to create such scripts for {post,pre}{inst,rm}.  I want to
> know whether my concerns are correct and would the use of `gettext' command
> be the only solutions for any shell?

I think so. It seems we have two possible ways to make a shell script to
talk "foreign" languages:

The "easy" one:

#!/bin/bash
export TEXTDOMAIN=fileutils
echo $"can not change to null group"
echo $"virtual memory exhausted"

The "portable" one:

#!/bin/sh
export TEXTDOMAIN=fileutils
gettext -s "can not change to null group"
gettext -s "virtual memory exhausted"


The "easy" one requires to have bash installed, and it will work only with
bash (does anybody know whether the $ feature of bash is mandated by the
POSIX standard?, I don't think so but who knows).

Having bash installed is not a problem, because it is essential, however,
I would dislike very much the idea of making every shell script to be
/bin/bash just to make it i18n. This would mean bash could never lose his
essential flag, and this is something I would like to happen some day.

The "portable" one requires to have gettext installed, and it should work
with any shell script. However, this would make many packages to depend on
gettext (if they want to have their shell scripts i18n'ed). Or maybe not,
the script could do a runtime check and use `echo' or `gettext' depending
on whether gettext is in the PATH or not. So people who want i18n would
install gettext, but having it not installed would not make it to fail.


Or maybe the right thing to do here is to do everything in C (?)

Opinions?

-- 
 "21728948110fe2a6cd2d7fb2423c0c6b" (a truly random sig)


Reply to: