Bugs item #632607, was opened at 2002-11-02 16:37 Message generated for change (Settings changed) made by bradleyhughes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=428680&aid=632607&group_id=40696
Category: source compiling issue >Group: 0.65.x >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Sergey Vlasov (vsu) >Assigned to: Bradley T. Hughes (bradleyhughes) Summary: translations aren't built with glibc 2.2 Initial Comment: The 'gencat' program since glibc 2.2.x requires setting the proper locale before compiling the message catalog file; without this it produces lots of messages like this: Translation.m:3: invalid character: message ignored The produced file does not contain any translations with non-ASCII characters and therefore is unusable. This problem can be solved by setting LC_ALL to the locale name for which the translations are compiled. Compiling different translations with the same locale settings does not work - especially if multibyte encodings are used (ja_JP and ko_KR). I'm not sure what will happen on the other systems, however... ---------------------------------------------------------------------- Comment By: SATO Satoru (ivibuf) Date: 2002-12-18 19:15 Message: Logged In: YES user_id=165662 I've also confirmed this problem. here is the log: $ LC_ALL=C gencat test_C.cat Translation.m Translation.m:3: invalid character: message ignored (snip) $ LC_ALL=ja_JP.eucJP gencat test_ja.cat Translation.m $ ls -l test_*.cat -rw-r--r-- 1 ss ss 540 Dec 19 03:02 test_C.cat -rw-r--r-- 1 ss ss 9501 Dec 19 03:03 test_ja.cat $ test_C.cat lacks most of all entries and is not usable. > I was under the impression this was only true if you left the locale to C, > even setting it to en_US seems to quiet the messages. that's not true; I also confirmed the problem is not disappeared when locale is set to LC_ALL=en_US. add to this, build commands should run in C locale (ex. rpmbuild looks setting locale to C). ---------------------------------------------------------------------- Comment By: Sergey Vlasov (vsu) Date: 2002-11-04 18:15 Message: Logged In: YES user_id=86260 The problem is that in some multibyte encodings (Japanese, Chinese) a character code like '\' or '\"' can be a second byte of a multibyte character. If such character is read with the en_US locale, such second byte will be interpreted wrongly. The exact same problem was present in some older versions of GNU gettext: old versions simply escaped such _bytes_ (not _characters_) with '\' - but after doing this the message catalog files were not valid in the specified multibyte encoding. Somewhere around gettext 0.10.40 this was fixed. ---------------------------------------------------------------------- Comment By: Sean 'Shaleh' Perry (shaleh) Date: 2002-11-04 01:06 Message: Logged In: YES user_id=37132 I was under the impression this was only true if you left the locale to C, even setting it to en_US seems to quiet the messages. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=428680&aid=632607&group_id=40696 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] List archives: http://asgardsrealm.net/lurker/splash/index.html Trouble? Contact [EMAIL PROTECTED]
