CLDR-17835 Fix light-speed problems

[macchiati]

CLDR-17835

The goal for type="speed-light-speed" is to be able to generate names for light-second, light-minute, and so on. In this cycle, that information was generated as a trial, allowing use to compare what the synthesized name for light-year would be against the extant names for light year.

Much of the data looks pretty good, but some was sufficiently bad that it needed deletion. There are also cases where the data for type="speed-light-speed" looks ok, but some additional structure needs to be added before it can be deployed in synthesized names. In particular:

• In some locales, the order of the components needs to be different, eg the equivalent of "year-light" (see https://it.wikipedia.org/wiki/Anno_luce)
• In some locales, the separator needs to be changed to space or removed.

This could be done changing the type="times" values, which provide the separator and order. But it appears that it needs to be refined, because 'light-" behaves a bit differently. For example French reverses the order for light-year (https://fr.wikipedia.org/wiki/Année-lumière), but does not for kilowatt-hour (https://fr.wikipedia.org/wiki/Kilowatt-heure)

We should be able to add some additional structure for those in the next cycle, but we are too close to release to do it in this cycle.

Locale file changes

• Most data changes were removals of type="speed-light-speed" that were clearly problematic
• Some were deletions of problematic type="duration-year", type="times", type="duration-light-year".
• Some were 'rescues', where it was clear from other items in the locale what the values should have been
  -example, common/main/ak.xml

tools/cldr-code/src/test/java/org/unicode/cldr/unittest/TestUnits.java

• Add tooling to show information about light-speed, light, year, light-year, and times patterns (in verbose mode)

• Use that information (see https://docs.google.com/spreadsheets/d/1LxzAysbtYQtbW1hIqlx0TpqMyv7PLv1vm_pB_sdpWM8/edit?gid=2062266520#gid=2062266520 to come up with a set of changes that fix the problematic cases.

• Use SearchXML to find the paths for all the the units in locales that have the issues.

  • For example, the following options were used to get the items that had problems with some paths for duration-year
  • -f^(tg|tt|xh|zu|ig|ti|yo)$
  • -p\Q@type="duration-year"\E
  • Note the use of \Q...\E to get a non-regex match, and the use of " to keep the console from removing the literal " marks

• In another sheet of the spreadsheet, refine the search results as input for modify_config

  • Change most fields from add to delete (This will cause them to inherit from root, and then be open for translation next time.
  • Delete some of the lines that were ok to keep
  • For add, look over the results to see where it was clear what could be retained.

• Run CLDRModify -fk to make the changes in the files.

• Review again, and create this PR.

• This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

[macchiati]

https://www.youtube.com/watch?v=3EI08o-IGYk

[macchiati]

I'd like to get this merged this morning if possible.

[sffc]

This PR causes most locales to inherit from root, instead of having localized translations for light-speed. They previously had localized translations. Seems like a bug?

[AEApple]

This PR causes most locales to inherit from root, instead of having localized translations for light-speed. They previously had localized translations. Seems like a bug?

We intentionally deleted problematic data, so I believe this is likely WAI until data is contributed during the next submission period. LMK if you think this is needed more urgently, and I can work with you to gather data offline for the 46.1 release.

[sffc]

I don't have a sense of the urgency; I just observe that this causes basically every language to have exactly 1 measurement unit in English while all others are translated into the local script. It looks jarring in the data file.

[macchiati]

This measure is special, only used in combination with second, minute, etc. It was a tossup whether to withdraw completely or not.

…

On Thu, Sep 26, 2024, 23:45 Shane F. Carr ***@***.***> wrote: I don't have a sense of the urgency; I just observe that this causes basically every language to have exactly 1 measurement unit in English while all others are translated into the local script. It looks jarring in the data file. — Reply to this email directly, view it on GitHub <#3984 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACJLEMEDE3MWJ4TDHYWN4RTZYT5JBAVCNFSM6AAAAABNE5GZ42VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNZYGUYTQNBWGU> . You are receiving this because you modified the open/close state.Message ID: ***@***.***>