Mail Archives: djgpp-workers/2000/04/26/08:12:57
Eli Zaretskii wrote:
> > > > 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 agree and I tolerate the libintl stuff, but if we can avoid adding yet another
layer I think it will be better.
> > > > 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.
Is that assuming the hook is very simple? because you can't put a hook in the
core of libintl in this way.
> > > 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.
Do you have any idea of how can it be? I generate the .mo (.gmo) files without
giving any information about encoding, and I generate PC437 and ISO-1 versions.
> > > > 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 ;-).
I mean: Currently there is no function to turn it off (because it doesn't exist),
so: are you planning to add a new one? it will add more and more conditionals.
I think the better way is to just modify the compilation process. I'm not too
familiar with autoconf/automake but I think it can be achieved using these tools.
You just need to modify the rules to create a .mo. Instead of just calling the
tool that converts .po to .mo you just recode the .po file into a temporal file
and then generate the .mo from the temporal.
As I see that's just around 2 or 3 lines in the makefile.
If you want to make it better you (well, not exactly you, anyone ;-) could make a
tool to replace msgfmt. That's simple because the name of msgfmt is supposed to
be easy to replace (see the makefiles, if the name is defined outside can be
changed).
This tool could do the trick:
1) Recode to a temporal (using the name as an heuristic to know the encoding).
2) Call the real msgfmt
3) Delete the temporal.
With this the changes are even smaller, just provide a different name for msgfmt
and a new tool in gettext package.
What about it?
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 -