[fpc-pascal] string comparison with strcomp
Hi, I'm stuck with some sort of nasty problem: While doing internationalization in a program planned only for german users I started to use the gettext mechanism to translate any descriptive GUI string. The mean part is that my original strings (now used as resourcestrings) do not work if they have german umlauts or the like in it. I want to avoid having to put anything to us-ascii first to get it done. >From looking at the sources of gettext.pp i know the comparison is done with "StrComp", but this is where I'm stuck. If i use e.g. 'ü' it is represented as \374 (it is $FC) as in: #: state1:srdataswap msgid " - Daten\374bertragung" msgstr "anything, testing only" in the .po file. But in translation the msgid is not found (testing with fr_FR as $LANG), but this here: #: conststr:srokay msgid "OK" msgstr "Oui" does work. In the .mo file the hex value is $FC as expected (in a hex viewer with french LANG var). Can someone explain to me what's wrong here and maybe how to get around it? TIA, Marc ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] string comparison with strcomp
Hallo Marc, I reported this a long time ago, and got an answer like: gettext doesn't accept source strings in UTF-8. The easiest way to solve it is to write the program in English (with english on buttons, etc) and then write a po file for german. I know, I know, not elegant or easy, but it works. Note that the strings must be edited with a UTF-8 editor. John On Sat, 09 Apr 2005 21:29:40 +0200 Marc Santhoff <[EMAIL PROTECTED]> wrote: > Hi, > > I'm stuck with some sort of nasty problem: > > While doing internationalization in a program planned only for german > users I started to use the gettext mechanism to translate any > descriptive GUI string. The mean part is that my original strings (now > used as resourcestrings) do not work if they have german umlauts or the > like in it. I want to avoid having to put anything to us-ascii first to > get it done. > > >From looking at the sources of gettext.pp i know the comparison is done > with "StrComp", but this is where I'm stuck. If i use e.g. 'ü' it is > represented as \374 (it is $FC) as in: > > #: state1:srdataswap > msgid " - Daten\374bertragung" > msgstr "anything, testing only" > > in the .po file. But in translation the msgid is not found (testing with > fr_FR as $LANG), but this here: > > #: conststr:srokay > msgid "OK" > msgstr "Oui" > > does work. In the .mo file the hex value is $FC as expected (in a hex > viewer with french LANG var). > > Can someone explain to me what's wrong here and maybe how to get around > it? > > TIA, > Marc > > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Basic routines
Hello, While writing the "pure Pascal" version of a big integer library (for FPC 2.0), I notice that the use of a very small assembler function lowers the average running time of the computations by about 30-35%. This is far from insignificant. Currently I use a macro to enable the x86 (32 bits) procedure, letting to the user the task to re-write it for other processors. But that's not a good idea ;-) So, it would be nice if such a routine were part of FPC. Here it is function UInt32x32To64(A,B: Longword): QWord; assembler; asm mull %edx end; Its use is 3 times as fast than "t := QWord(A)*B;". (Notice that this routine exists in the Windows SDK) I also have one concerning the division but, there, the "right" interface is less obvious and, contrary to the previous function, it might raise an exception. In fact, it would be sufficient that FPC uses ONLY one division for the following code: r := a mod b; q := a div b; to divide by two (almost) the running times of divisions of big integers by small ones. Would it be difficult to add the mul function to FPC? Thanks. mm ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] string comparison with strcomp
Am So, den 10.04.2005 schrieb John Coppens um 00:05: > Hallo Marc, Hi John, > I reported this a long time ago, and got an answer like: gettext doesn't > accept source strings in UTF-8. Ah, I see. This inspired me to do some further tests and I found a solution that is more acceptable than doing what I don't want to do. I found from some quick tests that it is rstconv that cannot handle the encoded strings. Replacing them in the generated .po file seems to do the trick. Needs more testing but might be okay when done by some shellscript ... :) > The easiest way to solve it is to write the program in English (with > english on buttons, etc) and then write a po file for german. I know, I > know, not elegant or easy, but it works. Note that the strings must be > edited with a UTF-8 editor. Yes, as a last solution I'd have to do it that way. Thank you very much, Marc -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
