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

CLDR Ticket #3831(closed defect: fixed)

Opened 6 years ago

Last modified 3 years ago

Require distinct values for narrow day periods

Reported by: pedberg Owned by: pedberg
Component: xxx-test Data Locale:
Phase: Review: emmons
Weeks: Data Xpath:




Although we do not require that narrow forms of names for days, months and quarters be distinct, we probably should for narrow forms of day periods (at least for AM and PM); there is less disambiguating context for them, and they are more likely to be used in a format that requires parsing.


Change History

comment:1 Changed 6 years ago by mark

  • Owner changed from somebody to pedberg
  • Priority changed from assess to major
  • Status changed from new to assigned
  • Milestone changed from UNSCH to 2.1m1

comment:2 Changed 6 years ago by pedberg

spec & test

comment:3 Changed 5 years ago by pedberg

  • Status changed from assigned to accepted
  • Milestone changed from 21m1 to 21m2

Hmm, can't currently build ConsoleCheckCLDR to test this.

comment:4 Changed 5 years ago by pedberg

  • Milestone changed from 21m2 to 21m1

comment:5 Changed 5 years ago by pedberg

  • Xref set to 4135 4136

OK, can build ConsoleCheckCLDR now (after updating CLDR and ICU4J, and making some fixes under this ticket).

It turns out there was no test for distinctness of date symbols within sets that are supposed to require distinctness (like format wide month names), so I am adding a general test for all date symbols that should have distinct values. This of course leads to the question of which ones those should be.

The spec currently says for month, day, and quarter names: "The format values must be distinct for the wide and abbreviated widths. However, values for the narrow width in either format or stand-alone contexts, as well as values for other widths in stand-alone contexts, need not be distinct; they might only be distinguished by context." It does not currently say anything about dayPeriod names (and the original intent of this bug is to address that), nor does it say anything about era names.

  1. dayPeriods: An initial thought is that all dayPeriod sets (format/standalone, wide/abbrev/narrow) should use names that are distinct with the set, since as noted in the ticket, "there is less disambiguating context for them, and they are more likely to be used in a format that requires parsing." However, that is not currently true. For example, zh has for format/wide:
            <dayPeriod type="am">上午</dayPeriod>
            <dayPeriod type="morning">上午</dayPeriod>
            <dayPeriod type="noon">中午</dayPeriod>
            <dayPeriod type="midDay">中午</dayPeriod>
            <dayPeriod type="pm">下午</dayPeriod>
            <dayPeriod type="afternoon">下午</dayPeriod>

Note sure whether this is a bug; filed cldrbug 4135: for this. Meanwhile, probably the test here should only generate warnings (not errors) for duplicate names that cover similar periods like am/morning or pm/afternoon.

  1. eras: I would think the same considerations apply to era name sets (wide/abbrev/narrow); they should be distinct within the sets. However, there is another current problem: it is currently not the case for Japanese-calendar abbreviated era names in root. The era names are distinct in the Japanese locale, but the transliterations are not distinct in root. For example:
    	<era type="148">ja: 正和, root: Shōwa (within gregorian years 1312-1317)
    	<era type="234">ja: 昭和, root: Shōwa (within gregorian years 1926-1989)

I have filed cldrbug 4136: for this. Meanwhile the test here should probably also just generate warnings for duplicate era names.

comment:6 Changed 5 years ago by pedberg

  • Review set to mark

OK, I have updated the spec too. All of this (tests and spec) may have to be updated per results of the discussions about cldrbug 4135: and cldrbug 4136: .

comment:7 Changed 5 years ago by srl

  • Review changed from mark to srl

comment:8 Changed 5 years ago by emmons

  • Status changed from accepted to closed
  • Resolution set to fixed
  • Review changed from srl to emmons

comment:9 Changed 3 years ago by emmons

  • Milestone 21m1 deleted

Milestone 21m1 deleted


Add a comment

Modify Ticket

as closed
Next status will be 'new'
Next status will be 'closed'

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

Note: See TracTickets for help on using tickets.