registry team mailing list archive

[Sense Hofstede <u@xxxxxxxxxxxxxxxx>]

The upstream maintainer writes the following:
"Quoting Sense Hofstede (sense@xxxxxxxxxx):
> > >From Matthew Paul Thomas:
> > "The Debian maintainers are correct about the ISO639-2 names. But those
> > names are not for selecting languages, they are for classifying
> > languages. A simple way to demonstrate this is to imagine if someone was
> > to translate Debian or Ubuntu into the Blackfoot language, and someone
> > else was to translate it into the Malecite-Passamaquoddy language.
> > Following ISO639-2 to the letter would require them both to be listed as
> > "Algonquian languages", which would be nonsense, because they're
> > mutually unintelligible languages. "Algonquian languages" is a useful
> > classification, but it's a useless identifier.
ISO 639-3 is meant for this. Malecite-Passamaquoddy has the "pqm"
code. No idea about the code for Blackfoot as I can't find it in the
standard (it may be listed with another name).

ISO-639-2 is known to be less precise than -3. This is why people who
create locales use -3 codes. And people who want to display a complete
list of languages should use it, too (good luck with 7704 entries).

> > I would be surprised if there is any software in Ubuntu *or* in Debian
> > that uses iso-codes for classifying languages, rather than for offering
> > language choices. So if iso-codes sticks exactly to ISO639-2, then it is
> > not fit for the purpose of offering language choices, and there needs to
> > be a language-codes package or something to override or replace it.
Just do it. 

And be prepared to deal with request with ${random_developer} who will
try to teach you that "this language should be named this way"
without, of course, no reference for properly and neutrallmy deal with
this.

This is why iso-codes is stuck to the standard and, as long as I'll be
one of its maintainers, will continue to be.

> > A much simpler solution, though, would be to recognize that the ISO639-2
> > list is also internally inconsistent. For example, it has items for
> > "English, Old (ca.450-1100)" and "English, Middle (1100-1500)" -- but it
> > doesn't have "English, Modern (1500-)", it just has "English". Greek
> > should be treated the same way.
> > 
> > The equivalent bug in Launchpad Translations was [Launchpad] bug 81158,
> > fixed in 2007."
Whether Rosetta maintainers want to play the game of renaming
languages is their problem. That's not a reason for us to do so in
iso-codes. And, well, taking Rosetta as reference when it comes at
i18n is not really convincing for me, I'm afraid.

So, sorry, for being harsh, but if someone feels that 
"Greek, Modern (1453-)" is awkward, then get the standard fixed, but
do not twist packages implementing the standard.

An option could be introducing "common_name" as we did for ISO-3166
because of the Taiwan issue (and later Macedonia issue). That may
happen....after the release of squeeze."

I remember seeing Greek being referenced to in a recent iso-codes
related changelog. Was this fixed in Ubuntu using a patch already?

-- 
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Debian.
https://bugs.launchpad.net/bugs/681872

Title:
  "Greek, Modern (1453-)" name contains distracting detail