Errors from testing production data for 39-alpha4
I see the following errors when testing production data for release-39-alpha4:
1. Remove dialect names that are supposed to match the ones generated from locale display patterns; but maybe that does not work for short variant?
2. Test assumes value is present but it has ↑↑↑ and gets removed; maybe change test?
Actually neither of these issues had to do with using CLDRFile non-resolved string value.
The first has to do with how to handle requests for display names that are both short and dialect-style (non-compound); the CLDR spec does not say which to give priority. The fr data in the main CLDR repo was as below, with the items removed as redundant for production data marked with '-'.
If we are just asking for the short dialect names for en_US or en_GB there is no issue, and the short names for en_GB/US are redundant. But if we ask for the name of something like "en_US_POSIX", they are not only non-redundant but actually harmful. We first get the dialect name for e.g. "anglais (É.-U.)", then convert parens to square brackets, and append other variant names using the standard localeDisplayPattern.
With data in the main repo, we were getting:
So I decided to remove the “short” entries for en_US/en_GNB in the main repo (they get stripped for production data anyway). With removal we get this, same as what we were getting with production data, which is better:
However for this particular case we might prefer the following, which would require a spec change to favor the request for short over the request for dialect-style (though that behavior might not be desired for all dialect-style names):
2. The second is more of an issue with the TestMissingStatus test. It was calling VettingViewer.getMissingStatus to verify that a particular unit display name was PRESENT. However, in French, that name currently has ↑↑↑ and gets stripped for production. But even though the value ultimately comes from root in either case, VettingViewer.getMissingStatus reports PRESENT if the item is present with ↑↑↑ and ABSENT if the item is stripped. So for the test, choose another unit display item that does not have ↑↑↑.
Issue might be test is using CLDRFile methods that returns non-resolved string value. COuld lazily create resolved file and check that if there is an initial failure.