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

CLDR Ticket #5512(closed task: fixed)

Opened 5 years ago

Last modified 4 years ago

Move <fields> to top level of <dates> element

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



Per TC discussion 2012-Dec-12: Move the <fields> element from its current location -
under <dates><calendars><calendar type="xxxx"> (with data only for "gregorian") -
to being directly under <dates>, and applicable to all calendars.

Involves change to DTD, data, LDMLConverter, and coordination with JDK.


1373476958.EXT (25.0 KB) - added by anonymous 4 years ago.

Change History

comment:1 Changed 5 years ago by pedberg

  • Owner changed from anybody to pedberg
  • Priority changed from assess to major
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 23dres

comment:2 Changed 5 years ago by pedberg

ICU needs to adjust for this, see http://bugs.icu-project.org/trac/ticket/9857

comment:3 Changed 5 years ago by pedberg

This is being done in two phases in order to not affect the current Survey Tool vetting for cy, hy, ka, mn.

Phase 1 (changeset 8073) does the following:

  • Update the DTD to add <fields> at the new location (it remains at the old location for backward compatibility anyway)
  • Update elementOrder in CLDRFile, supplementalMetadata to match
  • Update prettyPath and CheckConsistentCasing for the new location (leaving support for the old location too, for now)
  • Update ldml2icu_locale.txt so NewLDML2ICUConverter uses the new location
  • For most locales, just move the <fields> data to the new location. Special handling for the following: (a) root , en - copy <fields> to the new location, leaving it also in the old location for now; (2) cy, ka, hy, mn - add a version of <fields> in the new location using what is currently winning in the ST; leave alone whatever exists for <fields> at the old location (hy and mn did not have anything there)
  • Don't change the info that ST uses to find data, e.g. PathDescriptions.txt and PathHeader.txt; don't update coverage data for new paths.

This way ST will continue working with the existing data at its current location for the locales being modified, but I can also pre-integrate CLDR data into ICU with the new location, and update ICU code accordingly. Once the ST data is rolled into XML then I can do phase 2:

  • Update the <fields> data in the new location for cy, ka, hy, mn with the final winning values
  • Delete the <fields> data at the old location for root, en, cy, ka
  • Delete the support for the old <fields> location in prettyPath and CheckConsistentCasing
  • Update the ST info to use the new <fields> location
  • Update the deprecated info in supplementalMetadata
  • Update coverage data to use new paths

comment:4 Changed 5 years ago by pedberg

  • Review set to emmons

OK, made the final changes. John had already made some:

  • Under cldrbug 5637: update <fields> data in the new location for cy, ka, hy, mn with the final winning values and removed the data in the old location
  • Under this ticket: Update ST info in PathDescriptions.txt and PathHeader.txt

I just did this:

  • Remove <fields> data at the old location for root, en
  • Remove the support for testing the old location in CheckConsistentCasing (but leave the old paths in prettyPaths.txt, since it supports old paths too; it already had the new paths)
  • Update the coverage data to use the new <fields> location
  • Update the docs (and fix old validation errs as usual)

There does not seem to be a way in supplementalMetadata to deprecate an element only in one particular path and not another path, so I did not update the <deprecated> element.

comment:5 Changed 5 years ago by emmons

  • Status changed from accepted to closed
  • Resolution set to fixed

comment:6 Changed 5 years ago by srl

  • Xref set to 5961

note these were missed by coverage - CldrBug:5961

Downstream, DojoBug:17071

Changed 4 years ago by anonymous


comment:7 Changed 4 years ago by emmons

  • Milestone 23dres deleted

Milestone 23dres 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.