Mail Archives: djgpp-workers/2000/04/26/06:53:32
> 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 ;-).
- Raw text -