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

CLDR Ticket #9657(design)

Opened 2 years ago

Last modified 11 days ago

Mechanism for more stability?

Reported by: mark Owned by: mark
Component: to-assess Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:


Katsuo is going to file a bug that a number of the Japanese translations have changed, where the result is not clearly better than what we had (he thinks they are actually worse).

To maintain stability of translation, we really want to only change values if the result is clearly better (not just marginally better). We've discussed this before, but we might want to increase the voting weight required to change a value that has been stable for a while.

One idea would be to analyze the data to see the last time an item in a locale was changed.

  1. If it has been stable for 2 releases (ie, resulted from one previous data submission cycles), introduce a vote of 2 by the "CLDR" organization.
  2. For each release older than that, increase the vote by one, up to a maximum of 8.


In v30 data submission:

  • X gets 4 Apple votes, 4 Google votes
  • Y gets 4 MS votes

Suppose that the item is completely new. In that case, no votes are added and X wins as it would under the current rules.

Say that instead, Y was in the last release. We look at when Y was first introduced:

v28: Y gets 4 MS votes + 2 CLDR votes. X still wins
v26: Y gets 4 MS votes + 4 CLDR votes. It is a tie, so Y stays the same.

(same for older)


We could simplify http://cldr.unicode.org/index/process#TOC-Draft-Status-of-Optimal-Field-Value if we used this technique. For example, we would no longer need "established locales"; items (not locales) are "established" by being older.


Change History

comment:1 Changed 2 years ago by pedberg

  • Owner changed from anybody to mark
  • Status changed from new to design
  • type changed from unknown to data
  • Component changed from unknown to main
  • Milestone changed from UNSCH to 31

comment:2 Changed 2 years ago by kristi

See full notes on this discussion in CLDR agenda 11-16-2016.

Steps to assess past changes before implementing logic:

  1. Create a data file that shows changes over time (.csv) for a few locales. Also include Coverage info. (Mark)
  2. Validate with linguists on the reasoning for the changes captured in the data file.

comment:3 Changed 2 years ago by kent.karlsson14@…

I't already waaay too difficult to change erroneous values (that has been in several releases, but even so has not gotten sufficient attention by reviewers). Please don't make it even harder to fix them.

comment:4 Changed 2 years ago by mark

  • Phase changed from dsub to rc

comment:5 Changed 2 years ago by mark

  • Phase changed from rc to dvet

comment:6 Changed 23 months ago by mark

  • Phase changed from dvet to dsub
  • Milestone changed from 31 to 32

Can't get to this in v31

comment:7 Changed 18 months ago by mark

  • Priority changed from assess to critical
  • Milestone changed from 32 to 33

Not enough time for this, moving to 33 but bumping to critical.

comment:8 Changed 13 months ago by kristi

  • Milestone changed from 33 to 34

comment:9 Changed 7 months ago by mark

  • Priority changed from critical to major
  • Milestone changed from 34 to UNSCH

Other mechanisms look more promising

comment:10 Changed 7 weeks ago by mark

  • Component changed from main to other

comment:11 Changed 11 days ago by mark

  • Component changed from other to to-assess

Add a comment

Modify Ticket

as design

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

Note: See TracTickets for help on using tickets.