Mail Archives: djgpp-workers/2000/04/25/09:13:32
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
- Raw text -