Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#148 translations aren't built with glibc 2.2

0.65.x
closed-wont-fix
5
2014-08-19
2002-11-02
Sergey Vlasov
No

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...

Discussion

  • 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.

     
  • Sergey Vlasov
    Sergey Vlasov
    2002-11-04

    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.

     
  • SATO Satoru
    SATO Satoru
    2002-12-18

    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).

     
    • milestone: --> 0.65.x
    • assigned_to: nobody --> bradleyhughes
    • status: open --> closed-wont-fix