Sender: root AT delorie DOT com Message-ID: <3906EC04.71A8982D@inti.gov.ar> Date: Wed, 26 Apr 2000 10:15:49 -0300 From: salvador Organization: INTI X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.38 i686) X-Accept-Language: es-AR, en, es MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp-workers AT delorie DOT com Subject: Re: GNU Gettext and NLS support for DJGPP References: <3905A626 DOT CFC761CB AT inti DOT gov DOT ar> <200004261100 DOT HAA23646 AT indy DOT delorie DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com 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