Mail Archives: djgpp-workers/2000/04/24/09:43:29
Eli Zaretskii wrote:
> I think there's a need to discuss the way we want gettext to work with
> DJGPP ports. Let me begin this discussion by presenting the problem
> and the possible solutions.
>
> Gettext works by providing, for each package, a catalog of strings
> used by that package. For each supported language FOO, there is a
> corresponding FOO.po file (e.g., de.po for German, ko.po for Korean,
> pt.po for Portuguese, etc.) which holds translations of each of these
> strings to that language. At run time, a special function is called
> to translate each string before it is printed, by looking up the
> translation in the corresponding .po file.
Binary version of .po files are called .mo and that's what is usually
distributed with the binary packages (that's what the library uses).
[snip]
> It is possible to convert the *.po files to DOS codepages, e.g. using
> the `recode' program.
The problem is that then users must compile then into .mo files, and I don't
think that's a task for a regular user.
(.mo files can't be recoded without damage).
> However, this conversion should be done
> manually by each user, since the Makefile's supplied by the GNU
> packages don't have provisions for running any such programs when you
> say "make install".
>
> 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 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*.
2) A function to reload all the strings (that's a need for my editor because it
can change encodings on the fly ;-)
The only problem: when I commented it to a friend he told me gettext usually
maps the file in memory ... so these hooks aren't good for that case. Should
they be only in the DOS version?
The other option is hook the conversion but it will be much slower.
> One possible way to
> get this code for free is to link against librecode.a which is part of
> the `recode' package.
>
> I favor the second alternative, but it means some additional work on
> the gettext port.
And code bloat ...
The fact that .mo files aren't usable under DOS as-is is just a big fail in the
gettext stuff. 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.
IMHO gettext files (.mo) should say (internally) what encoding was used to
create these files and configure+make install process should allow users to
choose the encoding used for each file. That's not a problem that only affects
djgpp programs.
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.
In any case I think the lack of a hook in gettext is a big fault.
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 -