CLDR-17857 add whole-locale warning for missing English name

[srl295]

• warning, not error, otherwise we'd block builds!
• new subtype missingEnglishName
• also remove LogKnownIssues for CLDR-15663

CLDR-17857

• [ ] This PR completes the ticket.

ALLOW_MANY_COMMITS=true

[srl295]

Example output:

lld [Ladin]	warning	▸null◂	〈null〉	【】	〈null〉	«»	【】	⁅missing english name⁆	❮Warning: Missing English translation for lld❯	…
::warning file=lld.xml,title=missing english name:: Warning: Missing English translation for lld

[AEApple]

So will this just start failing when data is brought into vXML, or is there a way to get it to fail earlier in the cycle?

[srl295]

So will this just start failing when data is brought into vXML, or is there a way to get it to fail earlier in the cycle?

Good question. Two parts to the answer:

1. There's already a test. Once a locale reaches basic - and localeCoverage.txt is updated - tests will start failing as follows. These tests pass today, so there aren't any issues currently. This PR removes a logKnownIssues for locales below basic.

CLDR {
  LikelySubtagsTest {
    TestMissingInfoForLanguage {
      Error: (LikelySubtagsTest.java:345) Missing English translation for: zzz which is at basic
    } (0.268s) FAILED (1 failure(s))

This would fail after vxml import, and after updating the coverage levels. It's at that point that we would need to update English.

2. Secondly, this PR adds a new 'whole locale warning' - which will show up in the survey tool (once we no longer are suppressing those) and show up as a warning - in the locale - that the English name is missing.

[macchiati]

#2 does not appear to be the right answer, to me.

The TC is the body that wants to get the information that an English name for a code xxx is missing, not vetters in locale xxx.

[srl295]

#2 does not appear to be the right answer, to me.

The TC is the body that wants to get the information that an English name for a code xxx is missing, not vetters in locale xxx.

CLDR-15663 is titled "Ask for English version of language name when collecting Core data". So to expand on #2, I would say that if there still isn't an English version of the name when this warning shows up, the vetter could file a ticket, but it would be up to the TC to actually implement the change to English - at TC's discretion. The "ask" is to provide an input - not a definitive data point.

[AEApple]

Agreed, it seems like it would be nice if the error started showing up in en instead, and then we have en show up in the priority issues tracking?

[srl295]

Agreed, it seems like it would be nice if the error started showing up in en instead, and then we have en show up in the priority issues tracking?

That would be another way to do it. However, en is readonly, does anyone check en for errors at runtime in the survey tool? Edit OK. I stand corrected, there are errors in en. Still not clear where they would show up tracking-wise, that's why I thought in the locale (as with 'missing plural rules') made some sense. As with missing plural rules, it's an issue that cannot be fixed within the survey tool, which blocks progress towards coverage goals.

Edit2 would both make sense? A warning on the English side and on the locale side linking to that English warning? Then it would be in front of people looking at the locale side.

[AEApple]

We should just update priority issue tracking to include errors in en for future releases.

[macchiati]

Yes!

On Wed, Jul 31, 2024 at 9:01 PM Annemarie Apple @.***> wrote:

We should just update priority issue tracking to include errors in en for future releases.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3924#issuecomment-2261954313, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMFAG24XRSVQF3KXGRDZPGXH5AVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRHE2TIMZRGM . You are receiving this because your review was requested.Message ID: @.***>

[macchiati]

We also don't want errors in locales that vetters can't fix. What we want for all the whole-locale error is a report to the TC that we can view, NOT messages to vetters that they can't address.

On Wed, Jul 31, 2024 at 3:21 PM Steven R. Loomis @.***> wrote:

Agreed, it seems like it would be nice if the error started showing up in en instead, and then we have en show up in the priority issues tracking?

That would be another way to do it. However, en is readonly, does anyone check en for errors at runtime in the survey tool? Edit OK. I stand corrected, there are errors in en https://st.unicode.org/cldr-apps/v#/en/Territories/73c7c09de32184. Still not clear where they would show up tracking-wise, that's why I thought in the locale (as with 'missing plural rules') made some sense. As with missing plural rules, it's an issue that cannot be fixed within the survey tool, which blocks progress towards coverage goals.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3924#issuecomment-2261556411, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMDEN4AKNIBIQ5LT4ZTZPFPNBAVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGU2TMNBRGE . You are receiving this because your review was requested.Message ID: @.***>

[srl295]

I’m not quite getting the timeline/flow of responsibility for how these would be dealt with. I’ll write up a sketch of what I think you are suggesting (who does what when) as a reference for discussion.

[macchiati]

Yes, I think we need to discuss this in person rather than email (sorry if my message sounded harsh!).

On Sat, Aug 3, 2024 at 11:53 AM Steven R. Loomis @.***> wrote:

I’m not quite getting the timeline/flow of responsibility for how these would be dealt with. I’ll write up a sketch of what I think you are suggesting (who does what when) as a reference for discussion.

— Reply to this email directly, view it on GitHub https://github.com/unicode-org/cldr/pull/3924#issuecomment-2267100588, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJLEMFYKJHCWL476J75OL3ZPURLTAVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGEYDANJYHA . You are receiving this because your review was requested.Message ID: @.***>

[srl295]

Not at all. Just 100% agree on discussing !

[srl295]

I added a proposal to today's meeting agenda - will copy it back to the ticket after discussion.

[jira-pull-request-webhook[bot]]

Notice: the branch changed across the force-push!

• tools/cldr-code/src/main/java/org/unicode/cldr/test/CheckCLDR.java is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[srl295]

closing, see ticket