Date: Thu, 2 Aug 2001 09:55:19 +0300 (IDT)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: salvador <salvador AT inti DOT gov DOT ar>
cc: djgpp-workers AT delorie DOT com, JT Williams <jeffw AT darwin DOT sfbr DOT org>
Subject: Re: gettext port
In-Reply-To: <3B686787.A7366819@inti.gov.ar>
Message-ID: <Pine.SUN.3.91.1010802095501.28510H-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
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


On Wed, 1 Aug 2001, salvador wrote:

> > NLS support requires translation between different character sets,
> > like between ISO-8859-1 and the corresponding DOS codepage 850 (to
> > pick an example that is relevant for DJGPP).
> 
> Is that really true?

Yes, that's how recent versions of gettext work: you can have
on-the-fly translation of the messages to any charset that is capable
of supporting the language.  This means you don't need to several .mo
files one each for every possible encoding of the language: you just
have one version of the message catalogue, tell gettext what charset
you want to see on output, and libiconv takes care of the rest.

> In the past I shipped Linux version of my .mo files in ISO-8859-1 and DOS
> version in 850. So the installed translations match with the system.
> No translation needed, so no memory nor speed overhead was introduced.

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.