[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cobalt-developers] [CQ3-OSS] Sausalito and Locales



There are some problems with trying to
compile the Cobalt Qube 3 OSS version 1.4,
when using a modern version of gettext...

1)
It now complains about duplication of keys (the old one didn't care)
Patches to fix those are enroute. Just removing the duplicate entries...

affects: palette, base-swupdate.mod (in the usual mendo tree)

2)
There is a problem with the Eastern locales: (Japanese and the 2 Chinese)

>   Older versions of gettext assumed singlebyte characters.  Since
>   '\' is the escape character, all instances of byte 0x5C needed
>   to be escaped by doubling, "\\".  However, iconv-enabled gettext
>   understands multibyte characters.  In particular, there are
>   multibyte characters where the second byte is 0x5C.  Since
>   gettext now compares the complete multibyte character to '\',
>   rather than each byte individually, these instance of 0x5C must
>   *not* be escaped.
> 
>   Effectively, this is an incompatible API change that breaks po
>   files in various CJK encodings.  Chinese Big5 is particularly
>   prone to this.  msgfmt will abort on this error.  E.g.:
> 
>   zh_TW.Big5.po:906: invalid control sequence

Some limited success can be had by doing a s/\\\\/\\/g,
but for a real fix it requires some one that knows the
languages to go in and clean up the affected .po files ?

Us ignorant westerners just use XLOCALEPAT="ja zh_TW zh_CN"... :-)

3)
Running the Jcode module from Perl has some problems out-of-the-box.
(using the latest release, http://search.cpan.org/search?query=Jcode)

from "man perlocale", under "Temporarily fixing locale problems":

>   The two quickest fixes are either to render Perl silent about any
>   locale inconsistencies or to run Perl under the default locale "C".
> 
>   Perl can be run under the "C" locale by setting the environment vari-
>   able LC_ALL to "C".  This method is perhaps a bit more civilized than
>   the PERL_BADLANG approach, but setting LC_ALL (or other locale vari-
>   ables) may affect other programs as well, not just Perl.  In particu-
>   lar, external programs run from within Perl will see these changes.  If
>   you make the new settings permanent (read on), all programs you run see
>   the changes.  See ENVIRONMENT for the full list of relevant environment
>   variables and "USING LOCALES" for their effects in Perl.  Effects in
>   other programs are easily deducible.  For example, the variable LC_COL-
>   LATE may well affect your sort program (or whatever the program that
>      arranges `records' alphabetically in your system is called).

Easiest workaround is just using: export LC_ALL="en_US.ISO8859-1"


4)
The Makefile for mendo/gallery doesn't respect XLOCALEPAT for the RPM.

Here is a two-line patch to fix it:
--- mendo.orig/gallery/Makefile 2002-08-20 14:56:26.000000000 +0200
+++ mendo/gallery/Makefile      2003-07-19 09:54:45.000000000 +0200
@@ -49,7 +49,9 @@
        @find libImage -type f ! -path "*/CVS/*" -exec install -D -o root -g
root -m 644 {} $(WEBDIR)/{} \;
        @echo "installing locale-sensitive styles...";
        for i in `find locale -type f -name "*.xml"` ; do \
+           if echo "$$XLOCALEPAT" | grep "$$i" 2>/dev/null; then \
                echo "$$i" |sed "s/\// /g" | awk "{ print \$$1 \"/\" \$$2
\"/\" \$$3 \" \" \"$(STYLEDIR)/\" \$$3 \".\"
 \$$2 }" | xargs install -D -o root -g root -m 644 ; \
+           fi \
        done;
 
 ifdef CCETOPDIR



But it seems as though the latest version of msgfmt doesn't complain
about using the old -e or -E flags anymore, which is a good thing...
(before one had to use a wrapper to get rid of those deprecated flags)

--anders