This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Updating/adding locale for Ethiopia and Eritrea in GNU libc.
- From: Daniel Yacob <yacob at geez dot org>
- To: drepper at redhat dot com, yacob at geez dot org
- Cc: libc-alpha at sources dot redhat dot com, pere at hungry dot com
- Date: Sun, 06 Jul 2003 09:53:08 -0500
- Subject: Re: Updating/adding locale for Ethiopia and Eritrea in GNU libc.
Greetings,
Thanks again for the clarification. I have rewritten the locales to
to use copy-ing to exploit the reuse of common data to the maximum extent
I found possible. I was delighted to find that in doing so the locales
become much, much easier to maintain.
I have locales ready for cvs here: http://yacob.org/glibc-yeha.tar.gz
While they all build and work as expected they can still be enhanced.
There was one oddity that I never got over. Once collation data is
defined in a given locale, another locale can only "copy" data from the
reference locale a single time. At least this is the case when defining
a new script in the LC_COLLATE section.
Building "so_ET", for example, would generate the error:
am_ET:61: duplicate definition of script `ETHIOPIC'
Though "ETHIOPIC" is defined only a single time in am_ET and am_ET
compiles without issue. The work around was to use two reference
locales. am_ET would then be "copied" in the LC_COLLATE section,
following sections would copy data from "ti_ET".
The locale package contains an "ideal-but-broken" directory where
only the single reference locale is used. If anyone can find a way
to avoid the "duplicate definition" problem please inform me, I'd
rather work with a single reference locale. Could this be a localedef
bug or am I really importing data incorrectly?
Also, is there any change the ETHIOPIC collation definitions could
be moved into "iso14651_t1"? This might also avoid the above problem,
and other problems that stem from ethiopic collation being undefined
in locales of other regions.
thanks,
/Daniel