Project

General

Profile

Feature #1215

use localedef "copy" statements for UTF-8 ctype etc.

Added by Gordon Ross about 9 years ago. Updated about 9 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-07-14
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

The XPG4 localedef input grammar has a "copy" statement. (See:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap07.html#tag_07_03
and http://pubs.opengroup.org/onlinepubs/9699919799/utilities/localedef.html for details.)

Rather than edit our UTF-8 localedef input files at compile time (as introduced by the fix for issue 922) we should create under source code management a new common file, and use a "copy" statement in the localedef files to define the LC_CTYPE section of each. Might also be possibe for LC_COLLATE sections, if they turn out the same across many UTF-8 localedef files.

The motivation for this is mostly that big generated files a build time are an annoyance because you can't search their contents on web-based source browsers like bitbucket or github.
They also slow down the build a little.

History

#1

Updated by Gordon Ross about 9 years ago

Once "copy" (or some sort of include mechanism) is in place, an "extra credit" piece of follow-on work for this might be to make the packaging system aware of the fact that (i.e.) the two files below are identical, and some could be links to the others:

usr/lib/locale/en_US.UTF-8/LC_CTYPE/LCL_DATA
usr/lib/locale/en_CA.UTF-8/LC_CTYPE/LCL_DATA

#2

Updated by Yuri Pankov about 9 years ago

This means that we'll need one common locale package (locale-common?) which will be required by SUNWcs(?) and will contain LC_CTYPE data (all other locales will contain links to this file) and probably others.

#3

Updated by Garrett D'Amore about 9 years ago

I had contemplated using this, but had decided originally not to do it, because I wanted to minimize any edits or massaging I was performing on the locale data files from CLDR. I still think this is a valid reason to do what we're doing today.

Also available in: Atom PDF