Date: Fri, 03 Aug 2001 11:58:18 +0300
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
Sender: halo1 AT zahav DOT net DOT il
To: salvador AT inti DOT gov DOT ar
Message-Id: <9743-Fri03Aug2001115817+0300-eliz@is.elta.co.il>
X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.9
CC: djgpp-workers AT delorie DOT com, jeffw AT darwin DOT sfbr DOT org
In-reply-to: <3B69BE48.789DAFE4@inti.gov.ar> (message from salvador on Thu, 02
	Aug 2001 17:55:36 -0300)
Subject: Re: gettext port
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1010802095501 DOT 28510H-100000 AT is> <3B69BE48 DOT 789DAFE4 AT inti DOT gov DOT ar>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Thu, 02 Aug 2001 17:55:36 -0300
> From: salvador <salvador AT inti DOT gov DOT ar>
> >
> > But the downside is that you need to produce a separate message
> > catalogue for each possible codepage.  For example, with Cyrillic
> > languages, there are half a dozen possible encodings, maybe more.
> 
> I understand it, but in any case you need some user setup. How the program
> will know to what code page to translate?

As Juan explained, the user sets an environment variable which
includes the spec for the language and the preferred encoding.

> I don't see why the user can't just use recode to adjust the messages.

It's much easier to set a variable than run `recode'.  Also, the .po
files might not be available to begin with.

> Of course that's just a point of view, but I don't really like bloating
> executables like this.

Neither do I.  Which is why we are discussing ways to put some of the
tables on disk.

Anyway, for users who don't mind large executables, the current
operation of gettext is much better than the old one: it allows them
to build and use any package with minimum fuss.  I suspect that with
today's machine having 128MB of physical RAM as a matter of routine,
having a 2MB executable is not a big deal.

> Another thing: could we have a library stripped to the really used
> conversions? I mean, we won't need to translate messages in really bizarre
> encodings.

You can never know what bizarre encoding the user will want ;-)