We're updating the issue view to help you get more done. 

ST: how does child locale vetter know what's missing and what's inherited?

Description

For example, go to pt_PT around http://st.unicode.org/cldr-apps/v#/pt_PT/Languages_A_D/39702a0ee7bb83b9

The fields for Aleut and Algerian Arabic are both marked with a black X, showing that they are "missing" and the current localized value is displayed the same for both. In reality, if you go up one level to http://st.unicode.org/cldr-apps/v#/pt/Languages_A_D/39702a0ee7bb83b9 and look at the parent locale's values, Aleut has been translated but Algerian Arabic is just defaulting to the ISO code.

We should expose the inherited value's background better to the vetter, so they know which values are actually inherited from upstream and which are really missing.

Environment

xpath

None

locale

None

Status

Assignee

John Emmons

Reporter

Fredrik Stenshamn

tracReporter

fredrik

tracOwner

emmons

tracResolution

fixed

tracStatus

closed

Reviewer

Fredrik Stenshamn

phase

dvet

tracCreated

May 01, 2015, 11:04 PM

Components

Fix versions

Priority

major