Date: Wed, 26 Apr 2000 07:00:13 -0400 (EDT)
Message-Id: <200004261100.HAA23646@indy.delorie.com>
From: Eli Zaretskii <eliz AT delorie DOT com>
To: salvador AT inti DOT gov DOT ar
CC: djgpp-workers AT delorie DOT com
In-reply-to: <3905A626.CFC761CB@inti.gov.ar> (message from salvador on Tue, 25
	Apr 2000 11:05:26 -0300)
Subject: Re: GNU Gettext and NLS support for DJGPP
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000425111640 DOT 23128D-100000 AT is> <3905A626 DOT CFC761CB 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: Tue, 25 Apr 2000 11:06:32 -0300
> From: salvador <salvador AT inti DOT gov DOT ar>
>
> > > > 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.

Well, you can't add a major feature like i18n without bloating the
code and slowing it down at least to some degree.

As to ``hard to figure out'', I guess that depends on the programmer's
background.

> > > 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?

We could, for example, have the missing functionality in our libc.a.

> > 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.

Perhaps.  All I know is the encoding is in the .po and .gmo files, so
you could use that info if you wanted.

> > > 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?

I don't understand the question (or the problem).  Implementing a
no-op conversion doesn't seem like something that needs to be
explained ;-).