Skip to content
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

Conversation

macchiati
Copy link
Member

@macchiati macchiati commented Nov 27, 2024

CLDR-18129

common/dtd/ldml.dtd

  • for @match language@type, use nlocale (locales for names)

common/dtd/ldmlSupplemental.dtd

  • all @match changes:
  • languageAlias@type, use bc47-wellformed (locales for names), and list allowed ill-formed values
  • likelySubtag@from&to, use xlocale (which allows for compatibility cases like "iw"
  • pluralRules@locales, use xlocale but also allow "sh"
  • use validity/…/all for a few items (now that the default doesn't allow deprecated)

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

  • Tighten down the test to avoid deprecated languages, removing and/or changing some items.
  • Add XLocaleMatchValue, NLocaleMatchValue to allow for special cases

tools/cldr-code/src/main/java/org/unicode/cldr/util/MatchValue.java

  • tighten up validity/locale, validity/language, ... to disallow deprecated in the default case
  • introduced validity/locale/all, validity/language/all, ... for the special cases where we want to all deprecated
  • introduced validity/xlocale with exceptions for certain deprecated codes, for plural rules and likelySubtags
  • introduced validity/nlocale with exceptions for certain deprecated codes, for language names
  • allow for setting the status for each locale field separately
  • provide for subclassing to extend the language check

tools/cldr-code/src/main/java/org/unicode/cldr/util/SupplementalDataInfo.java
tools/cldr-code/src/main/java/org/unicode/cldr/util/Validity.java

  • Allow for testing validity against past versions

tools/cldr-code/src/main/java/org/unicode/cldr/util/UnitConverter.java

  • clean up some code that didn't allow for old versions

tools/cldr-code/src/test/java/org/unicode/cldr/unittest/TestAttributeValues.java

  • Enhance testing to print (warnln) details of which items caused failures.

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

@macchiati macchiati marked this pull request as ready for review November 28, 2024 22:07
Copy link
Contributor

@conradarcturus conradarcturus left a 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.

common/main/en.xml Show resolved Hide resolved
common/main/la.xml Show resolved Hide resolved
common/dtd/ldml.dtd Outdated Show resolved Hide resolved
common/main/fi.xml Show resolved Hide resolved
common/main/en.xml Show resolved Hide resolved
common/main/en.xml Show resolved Hide resolved
common/supplemental/supplementalData.xml Show resolved Hide resolved
exemplars/main/rna.xml Show resolved Hide resolved
@srl295
Copy link
Member

srl295 commented Nov 29, 2024

java code LGTM (with q's though)

Comment on lines 141 to +142
<language type="cr">Cree</language>
<language type="cr" alt="long">Woods Cree</language>
Copy link
Member

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>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<language type="cr">Cree</language>
<language type="cr" alt="long">Woods Cree</language>
<language type="cr">Woods Cree</language>

Copy link
Member Author

@macchiati macchiati Nov 29, 2024

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, ...).

Copy link
Member

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).

Copy link
Member Author

@macchiati macchiati Nov 30, 2024

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.

Copy link
Member

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Contributor

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.

Copy link
Contributor

@conradarcturus conradarcturus left a 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.

Comment on lines 141 to +142
<language type="cr">Cree</language>
<language type="cr" alt="long">Woods Cree</language>
Copy link
Contributor

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 {
Copy link
Contributor

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

Suggested change
public static class XLocaleMatchValue extends LocaleMatchValue {
public static class LocaleOrDeprecatedLocaleMatchValue extends LocaleMatchValue {

Copy link
Member Author

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";
Copy link
Contributor

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.

Suggested change
return "validity/locale-for-likely";
return "validity/locale-or-deprecated-locale";

Copy link
Member Author

@macchiati macchiati Dec 2, 2024

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.

@macchiati macchiati merged commit db1ba18 into unicode-org:main Dec 2, 2024
12 checks passed
@macchiati macchiati deleted the CLDR-18129-Code-to-investigate-identifier-validity branch December 2, 2024 17:32
@macchiati
Copy link
Member Author

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

@macchiati
Copy link
Member Author

I also looked at updating the @match documentation. I see a couple of different paths — thoughts welcome:

https://unicode-org.atlassian.net/browse/CLDR-18146

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants