Sender: root AT delorie DOT com
Message-ID: <3905A668.F62F9DE@inti.gov.ar>
Date: Tue, 25 Apr 2000 11:06:32 -0300
From: salvador <salvador AT inti DOT gov DOT ar>
Organization: INTI
X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.38 i686)
X-Accept-Language: es-AR, en, es
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: GNU Gettext and NLS support for DJGPP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Eli Zaretskii wrote:

> On Mon, 24 Apr 2000, salvador wrote:
>
> > > Another possibility is to perform the translation on the fly, at run
> > > time.  This would mean we need to augment the gettext sources with
> > > additional code that would convert all non-ASCII characters from their
> > > Unix encoding to the corresponding DOS encoding.
> >
> > Even when I don't like such a magic translations
>
> Care to explain why don't you like them?

Because they usually:
1) Enlarge the code.
2) Make it slower.
3) Are hard to figure out.

> > I really think gettext should have a hook to allow it.
> > But I think it should provide:
> >
> > 1) A function to process all the strings loaded from the .mo
> >    file. So we recode it *once*.
>
> We could provide these missing features ourselves, if we decide they
> are needed.

Sorry, I'm not sure I understand: you mean unofficial patches or djgpp specific
ones?

> > 2) A function to reload all the strings (that's a need for my editor
> >    because it can change encodings on the fly ;-)
>
> Why do you need to reload?

Because conversions are usually a non bidirectional operation.

>  All you need is to run a conversion code,
> like in 1), to convert from one encoding to another.  Assuming the
> conversions are lossless,

That's the problem, if some character doesn't exist in the other code page ...

> this should be possible and relatively easy,
> provided that you have a conversion library such as librecode.

I have my own tables because it helps me to create the fonts (the editor can set
the fonts when used in DOS full screen).

> > At first the are some mechanism to select the code page. I don't
> > remmember it and I don't know why it isn't really implemented. I think is
> > something with the names of the language directories.
>
> I don't understand what you are relating to here.  Are you talking
> about DOS or Unix?
>
> On Unix, you select the locale and the encoding by setting environment
> variables.  AFAIK, gettext does look at those (in `bindtextdomain').

The problem is the encoding! I know is possible to handle it, but current
distributions of Linux (and GNU tools used) doesn't really handle it.

> > IMHO gettext files (.mo) should say (internally) what encoding was used to
> > create these files
>
> I think the .gmo files do say how they are encoded.

I doubt it because you never feed this data into the tools involved in the
creation of the files.

> > In the case of my editor I have the spanish files encoded in PC437 and I use
> > recode for convertion to create the UNIX version of the files. I do it in the
> > installation process.
> > Using option 2 all the native files (used by RHIDE my editor and how
> > know what else) will break.
>
> They won't break if we support a no-op ``conversion'', for those files
> which are encoded natively.

How?

SET

--
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Visit my home page: http://welcome.to/SetSoft or
http://www.geocities.com/SiliconValley/Vista/6552/
Alternative e-mail: set-soft AT usa DOT net set AT computer DOT org
                    set AT ieee DOT org set-soft AT bigfoot DOT com
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA Phone: +(5411) 4759 0013