www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/02/04/01:47:20

Date: Sun, 4 Feb 2001 08:44:13 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender: eliz AT is
To: Bruno Haible <haible AT ilog DOT fr>
cc: djgpp-workers AT delorie DOT com,
Juan Manuel Guerrero <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Subject: Re: gettext pretest available
In-Reply-To: <14971.212.679293.634887@honolulu.ilog.fr>
Message-ID: <Pine.SUN.3.91.1010204083936.20547J@is>
MIME-Version: 1.0
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

On Fri, 2 Feb 2001, Bruno Haible wrote:

> > So, apart of the issue of porting the code, there's a separate and
> > not less important issue of converting the *.po and *.gmo files to the
> > encoding used by the target OS.  It would be nice if this issue could
> > be solved as part of the Gettext package as well.
> 
> This gettext pretest has the ability to do character set conversion on
> the fly, e.g. from ISO-8859-1 to CP437.

This is great news!

What does on-the-fly conversion do for characters which cannot be encoded 
with cp437 (if I take the above example)?

Can the target charset (cp437 in the above example) be changed 
dynamically at run time, or is it statically determined for each .po 
file at build time?

> Converting the .po or .gmo files is not the solution, because users
> normally don't have the msgfmt/msgunfmt programs available at runtime.

What Juan did was convert the files (with `recode') when the binary zip
ofthe ported package is prepared.  Since most DJGPP users don't build 
packages by themselves, this is a reasonable solution.

Of course, doing that automatically at run time is better.

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019