[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[cobalt-developers] [CQ3-OSS] Sausalito and Locales
- Subject: [cobalt-developers] [CQ3-OSS] Sausalito and Locales
- From: Anders <andersb@xxxxxxxxxxx>
- Date: Wed Jul 23 02:13:02 2003
- List-id: Discussion Forum for developers on Sun Cobalt Networks products <cobalt-developers.list.cobalt.com>
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