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

Trac Comment 7 by —2014-04-22T20:37:44.756Z

Milestone 23dres deleted

Trac Comment 6 by —2013-04-24T17:27:53.609Z

note these were missed by coverage -

Downstream, DojoBug:17071

Trac Comment 4 by —2013-02-01T07:14:32.033Z

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

• Under : 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.

Trac Comment 3 by —2013-01-24T23:37:02.980Z

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

Trac Comment 2 by —2013-01-16T19:21:02.468Z

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