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

CLDR Ticket #9505(closed unknown: fixed)

Opened 17 months ago

Last modified 5 weeks ago

Adjust Priority Items chart

Reported by: mark Owned by: mark
Component: unknown Data Locale:
Phase: dsub Review: emmons
Weeks: Data Xpath:
Xref:

ticket:9535

Description (last modified by mark) (diff)

The Priority Items is used to track progress in the ST. It could be improved to be more helpful.

  1. During Submission, it is most important to drive the Missing value to zero. But
    1. this does not need to include variants, such as en_CA. Those will inherit values from their parents, and any problems can be fixed during the Vetting phase.
    2. this does not need to include Serbian (Latin) at all, since that is generated. Swiss High german can be also autogenerated, then corrected.
  2. During Vetting, it is most important to resolve Errors, Disputed, Losing, and fix any child locale values that need it.

Attachments

Change History

comment:1 Changed 17 months ago by mark

  • Description modified (diff)

comment:2 Changed 17 months ago by fredrik

  • Xref set to 9535

Item 1a is highlighted in bug:9535

comment:3 Changed 17 months ago by mark

  • Owner changed from anybody to mark
  • Priority changed from assess to major
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 31

comment:4 Changed 10 months ago by mark

  • Milestone changed from 31 to 32

comment:5 Changed 5 months ago by mark

Not doing sr_Latn at this time. But the changes should fix ticket:9535 also:


I have been trying to work on the Missing section of the Dashboard for en-GB, but there seems to be an issue.
The entries that are marked as missing are only missing from CLDR cycle 29, but I have voted for the term in this cycle, cycle 30, and so has the Microsoft linguist. Can you please advise?
I have tried to add a new term in case that would remedy the situation, but when I click the green tick box in order to add a new term, no new term is created and my previous vote resets.

Last edited 5 months ago by mark (previous) (diff)

comment:6 Changed 5 months ago by mark

Reviewer: the changes should also fix ticket:9512 also. Please check and close 9512 if it does.

comment:7 Changed 5 months ago by mark

Specifically, the changes should fix 2 things.

  1. The number of Missing items in the dashboard and Priority items for sublocales (such as fr_CA) should go down (they should be at most the same as the parent locale's.
    • To check, look at the dashboard for fr and fr_CA, or other parent/child pairs.
  2. The number of Losing items should go down (no longer counts as losing you put in explicit value that is same as inherited).
    • To check, go to fr_CA, pick an item that is inherited. Add that item explicitly with + and then picking Winning.

comment:8 Changed 5 months ago by kristi

  1. Losing: Vote on Inheritance, Losing # increases, because the item is now set with Status=Contributed rather than Missing. I think your intension was to make this a Winning item if that’s the one that will be set for that locale?
  1. Missing: The total number is reset (this is your fix). However, when I add votes to Inehritance, the Missing number does not go down in the Dashboard view. For example, here’s my vote on inheritance. Missing stays at 120.

comment:9 Changed 5 months ago by mark

Good comments.

  1. Yes, some of the Missing may turn into Losing. If the user is voting for the winning value, that shouldn't happen. Can you check that?
  1. Right, the Missing vote won't go down unless you vote for an item that is also missing from the parent locale. That is, votes for inherited values won't change the missing.
    1. Note that in an ideal world, we wouldn't have translators work on the child locales until the parent locales have no Missing values. That way they can just pick the parent value if it is ok, and only otherwise add a different value.

comment:10 Changed 2 months ago by mark

  • Status changed from accepted to reviewing
  • Review set to kristi

comment:11 Changed 2 months ago by kristi

  • Status changed from reviewing to reviewfeedback

Mark,
I think it would be good to document the expectation in the Dashboard section of the Survey tool guide. (I can add once you return this back to me.)
http://cldr.unicode.org/index/survey-tool/guide#TOC-Best-practices-for-handling-items-in-each-category

Here are two points to be added out of this ticket. (Do these sound right? I don't think we need to add the Sr-Latn since auto-transliterated locales don't have vetters working on them anyways.)

points to add to the survey tool guide:

  1. For Sub-locales, "Missing" count is based on the Parent locale; thus, it will not be reduced independently of the parent locale missing data count.
  1. Votes on inheritance will show as Losing if it does not have enough votes to be Approved(even if it's the winning suggestion with Contributed status).

comment:12 Changed 7 weeks ago by mark

Missing could be reduced by adding to sublocale. But that shouldn't be how it is done. Ideally the parent locale is fully fleshed out, and the child locales are then just checked for cases where they must be different.

According to the code, it appears that the message for Losing isn't right; it just indicates that your org's value isn't winning.

However, can you file a separate ticket about this so you can close the bug if the code changes are ok?


I dug into the code in VotingResolver.java and VettingViewer.java to make sure I got the right info (need to package more nicely for users, of course). So I thought I'd go ahead and list everything here for completeness as long as I did that.

What shows up in the Dashboard is based on the Choice class, which is based on the VoteStatus and MissingStatus. I highlighted the ones you asked about.

Choice

  • Error — Error in value detected by tests
  • Losing — The value that your organization chose (overall) is not the winning value.
    • = VoteStatus.losing
  • Provisional — There are not enough votes for this item to be approved (and used).
    • = VoteStatus.provisionalOrWorse
  • Disputed — Different organizations are choosing different values. Please review to approve or reach consensus.
  • Warning — There was a warning on the value, detected by tests.
  • English Changed — (a special kind of warning) The English value has changed in CLDR, but the corresponding value for your language has not
  • New — The winning value was altered from the last-released CLDR value. (Informational) • Missing — Your current coverage level requires the item to be present.
    • = MissingStatus.ABSENT

VoteStatus (depends on org)

  • losing — your organization's resolved vote is for value X, but X is not winning. As far as I can tell from the code, it doesn't matter what the status is (approved or not).
  • disputed — means that your organization's votes are internally split across two or more items X and Y. OR,
  • provisionalOrWorse — the item wasn't approved or contributed
  • ok — none of the above (org is winning, no disputes, item is approved or contributed)
  • ok_novotes — there are no votes, but the value was approved or contributed in previous release. [I don't think this shows up in the dashboard]

MissingStatus (just depends on data)

  • ABSENT — there is no value, or the value is inherited from ROOT (or CODE_FALLBACK, which is effectively root).
  • PRESENT — there is a value either in this value or a parent ≠ root.
  • ALIASED — there is an aliased value (eg from narrow to short).
  • MISSING_OK — for certain fields, like orientation, we don't require values. So treated like PRESENT
  • ROOT_OK — for certain fields in en.xml the root value is ok. So treated like PRESENT

comment:13 Changed 7 weeks ago by mark

  • Status changed from reviewfeedback to reviewing

comment:14 Changed 7 weeks ago by kristi

  • Review changed from kristi to pedberg

Could you do the code review?

comment:15 Changed 7 weeks ago by kristi

  • Review changed from pedberg to emmons

sorry, meant to assign to John for code review.

comment:16 Changed 5 weeks ago by emmons

  • Status changed from reviewing to closed
  • Resolution set to fixed
View

Add a comment

Modify Ticket

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


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

 
Note: See TracTickets for help on using tickets.