-
Notifications
You must be signed in to change notification settings - Fork 382
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-18129 Investigate and fix (where necessary) invalid codes #4215
CLDR-18129 Investigate and fix (where necessary) invalid codes #4215
Conversation
…/…/all to get all Status values that are available for that LstrType
…ions (keyboard, etc)
…s deprecated, with no replacement)
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.
Great! Thanks for finding invalid codes and improving the checker.
I left some comments that I think will improve CLDR readability for external developers/users. Happy to go back on forth on these ideas if you like.
java code LGTM (with q's though) |
<language type="cr">Cree</language> | ||
<language type="cr" alt="long">Woods Cree</language> |
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.
I don't think this is a great situation. Woods Cree isn't a "longer" form of Cree.
Content (whether a document, an audio recording, etc.) isn't going to be just in Cree, it's going to be in Woods Cree, or Plains Cree, or Swampy Cree, etc. Perhaps the macrolanguage isn't helpful here and should be removed. (The pronunciation and orthography is distinct between these three, in both Latn and Cans scripts.)
For now, I kind of think the best and most consistent change would be <language type="cr">Woods Cree</language>
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.
<language type="cr">Cree</language> | |
<language type="cr" alt="long">Woods Cree</language> | |
<language type="cr">Woods Cree</language> |
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.
That would overturn from our long-standing policy for dealing with the compatibility mess that macrolangauges created.*
We don't say
- Tosk Albanian, but rather Albanian
- Standard Arabic, but rather Arabic
- Standard Estonian, but rather Estonian
- Eastern Yiddish, but rather Yiddish
- Northern Uzbek, but rather Uzbek
- Iranian Persian, but rather Persian (or Farsi)
and so on.
That is, we use the code and name of the macrolanguage for the predominant encompassed code. The one exception off the top of my head is for "zh", where we have:
<language type="zh">Chinese</language>
<language type="zh" alt="long">Mandarin Chinese</language>
So that's why it was "consistent" in following that model for Cree.
* If the macrolanguage policy had been consistently applied by ISO, they'd have made German (de) as a macrolanguage, and given a new code for Standard German (eg, dex?) as an encompassed language (and made the 30ish other Germans like Colonia Tovar German, Swiss German, Low German, and so on also be encompassed languages). And the same for many other languages (French, Hindi, ...).
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.
Would there be some option to have CLDR decide that cr isn't (Or isn't considered) a macrolanguage? And just allow cwd
to stand on its own?
I hear you about consistency but it does not work with the identity of the languages encompassed under cr.
The difference with German is that people do refer to de
as Deutsch whereas even the name of the language differs between cwd/crk/csw - nehenawewin, neheyawewin and nehethawewin (not respectively).
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.
Those appear to be just the same word with slightly different pronunciations in different dialects, according to https://en.wikipedia.org/wiki/Cree_language#Dialect_criteria, which is exposed because written Cree is more phonetic than English.
It's as if we said that there were 3 different names for English: /ˈɪŋɡlɪʃ/ (UK), /ˈɪŋlɪʃ/ (US), /ˈɪŋɡləʃ/ (AU).
(They also appear to be really different dialects, not different languages, at a least according to https://en.wikipedia.org/wiki/East_Cree)
We should take this up in further in our next meeting: I filed https://unicode-org.atlassian.net/browse/CLDR-18142 about this.
In the meantime, I'll put out a call for taking the ticket for 47. We can always reverse the change for cr should TC decide it.
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.
I'm fine to land and then discuss. And I know this is long standing policy and not new.
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.
Those appear to be just the same word with slightly different pronunciations in different dialects, according to https://en.wikipedia.org/wiki/Cree_language#Dialect_criteria, which is exposed because written Cree is more phonetic than English.
It's as if we said that there were 3 different names for English: /ˈɪŋɡlɪʃ/ (UK), /ˈɪŋlɪʃ/ (US), /ˈɪŋɡləʃ/ (AU).
(They also appear to be really different dialects, not different languages, at a least according to https://en.wikipedia.org/wiki/East_Cree)
We should take this up in further in our next meeting: I filed https://unicode-org.atlassian.net/browse/CLDR-18142 about this.
In the meantime, I'll put out a call for taking the ticket for 47. We can always reverse the change for cr should TC decide it.
Right but one is not more general or more representative than the other. There are vocabulary differences as well.
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.
Generality, representativity, vocabulary differences, are not relevant to choosing the predominant encompassed language.
As I said, let's discuss in the meeting.
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.
As you mentioned, this change isn't about Macrolanguages -- it's about validity. So I'll accept to unblock. We probably don't have enough time to properly discuss the issue before the new year anyway, so let's not get ahead of ourselves.
We should follow up in a separate ticket -- but decide the timeline for this.
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.
Accepting to unblock. Any comments are stylistic or part of a bigger conversation that should not block this particular change.
<language type="cr">Cree</language> | ||
<language type="cr" alt="long">Woods Cree</language> |
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.
As you mentioned, this change isn't about Macrolanguages -- it's about validity. So I'll accept to unblock. We probably don't have enough time to properly discuss the issue before the new year anyway, so let's not get ahead of ourselves.
We should follow up in a separate ticket -- but decide the timeline for this.
* Check for the language OR certain backwards-compatible exceptions for data to support | ||
* retaining variants, namely likelySubtags: "in","iw","ji","jw","mo","tl" | ||
*/ | ||
public static class XLocaleMatchValue extends LocaleMatchValue { |
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.
personal style nit (you can choose your own style): have the explanation in the name
public static class XLocaleMatchValue extends LocaleMatchValue { | |
public static class LocaleOrDeprecatedLocaleMatchValue extends LocaleMatchValue { |
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.
Thanks!
|
||
@Override | ||
public String getName() { | ||
return "validity/locale-for-likely"; |
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.
personal style nit (you can choose your own style): don't label "why", rather label "what". Why is good in comments where it is used, but this function doesn't itself matter for likely subtags -- and it COULD matter for other usages.
return "validity/locale-for-likely"; | |
return "validity/locale-or-deprecated-locale"; |
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.
The problem is that or-deprecated is not true. It is only certain deprecated codes. Spelling out exactly what the criteria are is best left for documentation, since it would be quite long.
I have a separate issue for Cree (https://unicode-org.atlassian.net/browse/CLDR-18142), and a connected issue for the closely-related issue https://unicode-org.atlassian.net/browse/CLDR-18144 Improve formats of locales in menus |
I also looked at updating the @match documentation. I see a couple of different paths — thoughts welcome: |
CLDR-18129
common/dtd/ldml.dtd
common/dtd/ldmlSupplemental.dtd
common/main/en.xml
common/main/fi.xml
common/main/la.xml
common/main/nl.xml
exemplars/main/rna.xml
common/supplemental/supplementalData.xml
common/supplemental/supplementalMetadata.xml
common/validity/language.xml
tools/cldr-code/src/main/java/org/unicode/cldr/util/MatchValue.java
tools/cldr-code/src/main/java/org/unicode/cldr/util/SupplementalDataInfo.java
tools/cldr-code/src/main/java/org/unicode/cldr/util/Validity.java
tools/cldr-code/src/main/java/org/unicode/cldr/util/UnitConverter.java
tools/cldr-code/src/test/java/org/unicode/cldr/unittest/TestAttributeValues.java
tools/cldr-code/src/test/java/org/unicode/cldr/unittest/TestBasic.java
Add compatibility test for bcp47 to ensure that identifiers never disappear
This PR completes the ticket.
ALLOW_MANY_COMMITS=true