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

CLDR Ticket #11103(reviewing)

Opened 7 months ago

Last modified 2 weeks ago

Vote Status information for sub locales are carried over from the main locale

Reported by: kristi Owned by: tbishop
Component: surveytool-other Data Locale:
Phase: dsub Review: mark
Weeks: Data Xpath:
Xref:

Description

It looks like the voting information (the check marks indicating Approved,Contributed, etc..) are getting carried down to sub locales from main locales for those that have not

It's difficult to tell which are locales that people vetted on vs. those that are just getting the inherited.

For example see ko_KP which I'm fairly sure we haven't had any contributors.
another example is ar_MR which I'm also pretty certain that we haven't had any contributors.

In both cases they are all inherited values and show the same voting status as the main locale.
http://st.unicode.org/cldr-apps/v#/ar_MR/Gregorian/1d02739166125786
http://st.unicode.org/cldr-apps/v#/ko_KP/Gregorian/3adf0c8c69672074

Attachments

fr_CA examples with Missing status.JPG (50.3 KB) - added by kristi 7 months ago.
sub-locale data with X (missing) while the main locale has data

Change History

comment:1 Changed 7 months ago by mark

  • Owner changed from anybody to mark
  • Status changed from new to accepted
  • Milestone changed from UNSCH to 34

take a look

comment:2 Changed 7 months ago by kristi

Found some exceptions to what's happening.
These emoji entries are not inheriting the vote status from fr:
http://cldrubs14-test1.cloudapp.net/smoketest/v#/fr_CA/Food_Drink/14c5d3f5c66dd5c6

Changed 7 months ago by kristi

sub-locale data with X (missing) while the main locale has data

comment:3 Changed 6 months ago by mark

  • Component changed from unknown to survey

comment:4 Changed 6 months ago by mark

  • type changed from unknown to survey

comment:5 Changed 4 months ago by kristi

Some locales like ar-SA when all are inherited with no actual votes, it choses the check.
http://st.unicode.org/cldr-apps/v#/ar_SA/Hebrew/1a4cc4c92cb3c872

But in Maori for example, for values where there are no actual votes, it shows the X.http://st.unicode.org/cldr-apps/v#/mi/Gregorian/74f6f850b98466a2

comment:6 Changed 4 months ago by tbishop

  • Owner changed from mark to tbishop

comment:7 Changed 3 months ago by tbishop

  • Keywords inheritance added
  • Milestone changed from 34 to 35

comment:8 Changed 3 months ago by tbishop

For the first example

http://st.unicode.org/cldr-apps/v#/ar_MR/Gregorian/1d02739166125786

there is currently a green check mark in the A column, with tooltip "Status: Approved". What would be the correct status? Intuitively, given no votes in the sublocale, isn't inheritance automatic, and in some sense automatically "approved" if the inherited value was approved in the parent locale?

comment:9 Changed 2 months ago by kristi

For implementation design, see Vote design doc section "Check Mark (Voting Status) behavior"

"if the item is inherited, but not from root, and in the source locale has a value with enough votes, then the icon is a new icon ⇧ (orange color). (add this to TOC-Icons after implementation)
Otherwise it is an X (“does not have enough votes” as in TOC-Icons)"

comment:10 Changed 7 weeks ago by kristi

  • Priority changed from assess to major

comment:11 Changed 5 weeks ago by mark

  • Priority changed from major to critical

comment:12 Changed 4 weeks ago by tbishop

The icon is based on the value of winningStatus, sent from the server to the client as voteResolver.winningStatus in SurveyAjax.JSONWriter.wrap(VoteResolver):

        public static JSONObject wrap(final VoteResolver<String> r) throws JSONException {
            JSONObject ret = new JSONObject().put("raw", r.toString()).put("isDisputed", r.isDisputed())
                .put("lastReleaseStatus", r.getLastReleaseStatus())
                .put("winningValue", r.getWinningValue())
                .put("lastReleaseValue", r.getLastReleaseValue())
                .put("requiredVotes", r.getRequiredVotes())
                .put("winningStatus", r.getWinningStatus());

getWinningStatus is in VoteResolver.java:

    public Status getWinningStatus() {
        if (!resolved) {
            resolveVotes();
        }
        return winningStatus;
    }

resolveVotes starts like this:

    private void resolveVotes() {
        resolved = true;
        // get the votes for each organization
        valuesWithSameVotes.clear();
        totals = organizationToValueAndVote.getTotals(conflictedOrganizations);
        /* Note: getKeysetSortedByCount actually returns a LinkedHashSet, "with predictable iteration order". */
        final Set<T> sortedValues = totals.getKeysetSortedByCount(false, votesThenUcaCollator);
        if (DEBUG) {
            System.out.println("sortedValues :" + sortedValues.toString());
        }
        // if there are no (unconflicted) votes, return lastRelease
        if (sortedValues.size() == 0) {
            if (trunkStatus != null && (lastReleaseStatus == null || trunkStatus.compareTo(lastReleaseStatus) >= 0)) {
                winningStatus = trunkStatus;
                winningValue = trunkValue;
            } else {
                winningStatus = lastReleaseStatus;
                winningValue = lastReleaseValue;
            }
            valuesWithSameVotes.add(winningValue); // may be null
            return;
        }

comment:13 Changed 4 weeks ago by tbishop

I'm using http://localhost:8080/cldr-apps/v#/ar_MR/Gregorian/1d02739166125786 as the URL for testing. It shows a green checkmark for the inherited winning value, and there are no votes. resolveVotes sets winningStatus = lastReleaseStatus. Prior to that, the constructor for DataRow does:

           VoteResolver<String> resolver = ballotBox.getResolver(xpath);

getResolver (for ar_MR) calls ... getResolverInternal which calls:

    r.setLastRelease(lastValue, lastValue == null ? Status.missing : lastStatus); /* add the last release value */

with lastValue = إثنين and lastStatus = approved

    public void setLastRelease(T lastReleaseValue, Status lastReleaseStatus) {
        this.lastReleaseValue = lastReleaseValue;
        this.lastReleaseStatus = lastReleaseStatus == null ? Status.missing : lastReleaseStatus;
Last edited 4 weeks ago by tbishop (previous) (diff)

comment:14 Changed 4 weeks ago by tbishop

It appears that the status we're generally seeing is from the last release, not from the source for inheritance. The value is marked both with a star for last release and with blue background for inheritance. Coincidentally the inherited value and the last release value are the same, as is often the case. Nevertheless, the item is winning because it's last release, not because it's inherited.

Last edited 4 weeks ago by tbishop (previous) (diff)

comment:15 Changed 4 weeks ago by tbishop

In STFactory.getResolverInternal:

            final Status lastStatus = getStatus(anOldFile, path, lastValue);

getStatus returns Status.approved:

        private Status getStatus(CLDRFile anOldFile, String path, final String lastValue) {
            Status lastStatus;
            {
                XPathParts xpp = new XPathParts(null, null);
                String fullXPath = anOldFile.getFullXPath(path);
                if (fullXPath == null)
                    fullXPath = path; // throw new
                // InternalError("null full xpath for " +
                // path);
                xpp.set(fullXPath);
                String draft = xpp.getAttributeValue(-1, LDMLConstants.DRAFT);
                lastStatus = draft == null ? Status.approved : VoteResolver.Status.fromString(draft);

There we have draft == null.

comment:16 Changed 4 weeks ago by tbishop

This URL shows an orange checkmark: http://localhost:8080/cldr-apps/v#/ko_KP/Gregorian/3adf0c8c69672074

This time draft isn't null, and we get Status.contributed here:

   lastStatus = draft == null ? Status.approved : VoteResolver.Status.fromString(draft);

comment:17 Changed 3 weeks ago by tbishop

I made a branch (branches/tbishop/t11103_orange_arrow) and committed some basic changes for a first approximation. There's one new icon, "inherited.png", and orange up-arrow. There's one new Status value in VoteResolver, "inherited".

There are two places in VoteResolver where winningStatus gets "inherited" if winningValue is INHERITANCE_MARKER:

    private void resolveVotes() {
 ...
        // if there are no (unconflicted) votes, return lastRelease
        if (sortedValues.size() == 0) {
            if (trunkStatus != null && (lastReleaseStatus == null || trunkStatus.compareTo(lastReleaseStatus) >= 0)) {
                winningStatus = trunkStatus;
                winningValue = trunkValue;
            } else {
                winningStatus = lastReleaseStatus;
                if (CldrUtility.INHERITANCE_MARKER.equals(lastReleaseValue)) {
                    winningStatus = Status.inherited;
                }
                winningValue = lastReleaseValue;
            }
...

and

    private Status computeStatus(long weight1, long weight2, Status oldStatus) {
        if (CldrUtility.INHERITANCE_MARKER.equals(winningValue)) {
            return Status.inherited;
        }
        int orgCount = organizationToValueAndVote.getOrgCount(winningValue);
        return weight1 > weight2 &&
            (weight1 >= requiredVotes) ? Status.approved
                : weight1 > weight2 &&
                    (weight1 >= 4 && Status.contributed.compareTo(oldStatus) > 0
                        || weight1 >= 2 && orgCount >= 2) ? Status.contributed
                            : weight1 >= weight2 && weight1 >= 2 ? Status.provisional
                                : Status.unconfirmed;

I expect those aren't quite the right conditions for display of the new icon. Also, we still have some design decisions, whether to have more than one new icon, maybe different colors corresponding to the status in the parent locale. Also there are cases in which winningValue is determined, not by VoteResolver (which returns null) but by DataRow.fixWinningValue(); ideally that code, or a replacement for it, belongs in VoteResolver.

comment:18 Changed 3 weeks ago by tbishop

Committed changes to trunk with revision [14691]. Different from last version in branch: orange up-arrow is shown if winning item is inherited and doesn’t have the votes for a checkmark.

comment:19 Changed 3 weeks ago by tbishop

I forgot to include TestSTFactory.xml which needs one change from "provisional" to "inherited".

That's in revision [14692].

comment:20 Changed 2 weeks ago by tbishop

I’ve tested on smoketest. The only unexpected result is (3), and I believe it’s due to different voting data on smoketest (on which it currently shows zero votes, for v35) from my current localhost (on which it still has votes, for v34). In fact, if I vote for inheritance on smoketest, then it does change to a green check.

Current results on smoketest are:

(1) http://cldr-smoke.unicode.org/smoketest/v#/ar_MR/Gregorian/62c54e2eae198430 - green check

(2) http://cldr-smoke.unicode.org/smoketest/v#/ko_KP/Gregorian/3adf0c8c69672074 - orange up-arrow

(3) http://cldr-smoke.unicode.org/smoketest/v#/fr_CA/T_Europe/5f98c60333499cae - orange up-arrow

(4) http://cldr-smoke.unicode.org/smoketest/v#/fr_CA/T_Europe/2b8dc7b7161b41be - black X

comment:21 Changed 2 weeks ago by markus

  • Summary changed from Vote Status informaiton for sub locales are carried over from the main locale to Vote Status information for sub locales are carried over from the main locale

comment:22 Changed 2 weeks ago by tbishop

  • Status changed from accepted to reviewing
  • Review set to mark
View

Add a comment

Modify Ticket

Action
as reviewing
Author


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

 
Note: See TracTickets for help on using tickets.