-
Notifications
You must be signed in to change notification settings - Fork 384
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLDR-17857 add whole-locale warning for missing English name #3924
base: main
Are you sure you want to change the base?
Conversation
- no logKnown issue is needed, the test is already correct. - English translation will not be needed until coverageLocales.txt is updated.
- warning, not error, otherwise we'd block builds! - new subtype missingEnglishName
Example output:
|
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:
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 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. |
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, 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. |
We should just update priority issue tracking to include errors in en for future releases. |
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
<#3924 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMFAG24XRSVQF3KXGRDZPGXH5AVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRHE2TIMZRGM>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
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
<#3924 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMDEN4AKNIBIQ5LT4ZTZPFPNBAVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRRGU2TMNBRGE>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't think this is the best approach, but let's discuss
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.
|
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
<#3924 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACJLEMFYKJHCWL476J75OL3ZPURLTAVCNFSM6AAAAABLZCOBQCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENRXGEYDANJYHA>
.
You are receiving this because your review was requested.Message ID:
***@***.***>
|
Not at all. Just 100% agree on discussing !
|
I added a proposal to today's meeting agenda - will copy it back to the ticket after discussion. |
CLDR-17857
ALLOW_MANY_COMMITS=true