[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #10996(design)

Opened 12 months ago

Last modified 4 months ago

Add Open Location Codes to -u- extension

Reported by: mark Owned by: mark
Component: locale-codes-names Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

The subdivision codes (en-u-sd-xx) provide a certain level of granularity, but don't exist for all countries, and are not granular enough for some purposes.

A finer grained approach could use the Open Location Codes (aka pluscodes), which allow for successive degrees of refinement where necessary, such as when distinguishing usage variants that are characteristic of a part of a country or subdivision. It would also not some of the issues with countries/subdivisions: code stability, lack of subdivisions for a country, or changing boundaries.

Example:


Should we decide to do this, the codes would need only minor modification to work with BCP47.

I'd suggest:

  • If a code is smaller than 3 sig. alphanums, use one piece.
  • If a code is greater than 8 sig. alphanums, break into multiple pieces, with the initial ones being 8 in length.
  • Drop trailing zeros from each piece.
  • Pad any pieces of 2 or fewer alphanum with 0 to bring them up to length 3.

Thus

  • 6P000000+ => en-SG-u-pc-6P0
  • 6PH57VP3+PQ9 => en-SG-u-pc-6PH57VP3-PQ9

In the future, if we really wanted to signify usage that is also characteristic of usage as of a particular date, or date range, that could be easily done.


See
https://en.wikipedia.org/wiki/Open_Location_Code
https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc

Attachments

Change History

comment:1 Changed 11 months ago by srl

discuss interaction with existing locode (timezone)

comment:2 Changed 11 months ago by mark

This is independent of the locodes, which cover a very very small fraction of what the Open Location Codes can cover.

comment:3 Changed 10 months ago by doug@…

Open Location Codes are defined by a free and open specification, but appear thus far to have been implemented only by Google. Despite the technical merits of the system over similar latitude/longitude encodings, it may be prudent to avoid the appearance of using CLDR to promote what is essentially a Google invention.

The benefits of specifying locale data for an area smaller than 275 × 275 meters, necessitating multiple pieces, are also unclear. Concrete examples of usage that may differ between central Singapore and Woodlands, say, or between Chicago and Evanston, might be helpful.

comment:4 Changed 4 months ago by mark

  • Milestone changed from UNSCH to to-assess

comment:5 Changed 4 months ago by mark

  • Owner changed from anybody to mark
  • Priority changed from assess to medium
  • Status changed from new to design
  • Component changed from unknown to locale-codes
  • Milestone changed from to-assess to 36-optional
View

Add a comment

Modify Ticket

Action
as design
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.