This is the mail archive of the libc-locales@sources.redhat.com mailing list for the GNU libc locales project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Collating bug with period?


On Wed, Apr 06, 2005 at 11:25:19AM +0200, Keld Jørn Simonsen wrote:
[...]
> What do yoy mean by "not scaling"? Glibc has a mechanism "reorder-after"
> that can build on an existing LC_COLLATE spec and then just reorder a
> few characters, like the PERIOD character. This functionality is also
> included in ISO 14651 and TR 14652.

While you are talking about TR 14652, I have questions about its
LC_COLLATE definition.  The 'copy' keyword is defined by:
  copy   Specify the name of an existing FDCC-set to be
         used as the source for the definition of this
         category. If this keyword is specified, only the
         "reorder-after", "reorder-end", "reorder-scripts-
         after" and "reorder-scripts-end" keywords may
         also be specified. The FDCC-set shall be copied
         in source form.

This is very annoying, because new collation symbols can not be defined.
For instance, appendix B.2 (about Danish delta) of ISO 14651 cannot be
implemented as a tailoring delta because 'collating-element' and
'collating-symbol' keywords must be added after 'copy'.
It is also not clear why multiple 'copy' are not valid (om_ET locale
uses two 'copy').
And toogling keywords are also not allowed in conjunction with 'copy',
so the "gensort" example from TR 14652 is not valid.

Why all these restrictions about this 'copy' keyword?  It should work
like an 'include' statement, otherwise it is pretty useless.

Denis


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]