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

[Matthew Paul Thomas]

iso-codes 3.17-1, Ubuntu 10.10

1. Launch a utility that lists language names in your chosen language, e.g. Ubuntu's language-selector.
2. Scroll through the list of languages.

What you see:
* Greek is listed as "Greek, Modern (1453-)".
* No other kind of Greek is listed.
* No other listed language contains a date in its name, except for Occitan (which is a bug too).

What you should see:
* Greek is listed simply as "Greek".

Even if there was any software using iso-codes that usefully displayed "Greek, Ancient" as an option, it would still be obvious what "Greek" meant in contrast to that.

Any fix for this bug probably needs to be done in Debian. Fixing this bug would alter the fix required for bug 267513.

[Sense Egbert Hofstede (sense)]

Thank you for helping with making Ubuntu better by reporting this bug. I'm accepting this issue as a valid papercut, because it affects the way a part of the interface makes users feel, and am forwarding this bug to the Debian BTS. This issue indeed needs to be fixed in Debian, as Ubuntu simply syncs this package.

Although I encourage everyone to work on this bug, I would like to ask to send a possible patch to the bug report in Debian BTS, as fixing this issue should be done there.

[Sense Egbert Hofstede (sense)]

I have confirmed this bug myself in Debian unstable's iso-codes 3.22-1 and have forwarded the issue upstream. Therefore I'm marking it as Triaged. Because this is affecting usability, albeit it not too intrusively, I'm setting the priority to Low.

[Sense Egbert Hofstede (sense)]

The Debian bug report has been marked as "Won't Fix", because the maintainers don't like to deviate from the official standard. The current naming of Greek is the ISO standard, which can be observed at <http://www.loc.gov/standards/iso639-2/php/code_list.php>, and they do not want to change that.

"We won't change the standard. iso-codes is a package that provides a
list of names as they are in a standard.

Unless one of my comaintainers wants to add the "common name" hack we
had to introduce to deal with the Taiwan issue, I'm not keen to go
this way and play with names coming from the standard."

There are more oddities in the list. I discovered that the official name for the language with the code 'nld' is "Dutch; Flemish", even though Flemish doesn't exist as a separate language. Calling Dutch Flemish makes just as much sense as naming 'en-GB' "English; Kentish". Although adhering to an internationally accepted specification saves us work and prevents stepping on sensitive toes, we should consider whether the names used for languages are not confusing or even incorrect.

[Matthew Paul Thomas (mpt)]

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.

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.

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 bug 81158, fixed in 2007.

[Sense Egbert Hofstede (sense)]

The upstream maintainer writes the following:
"Quoting Sense Hofstede (<email address hidden>):
> > >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?

[Robert Roth (evfool)]

The latest change of iso-codes happened in bzr on 12-01 (http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/natty/iso-codes/natty/revision/27), but that wasn't an Ubuntu-specific patch, but an upstream release imported, where Greek was mentioned because the Greek translation of level2 d-i was updated, fixing http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=604448, but that has nothing to do with this bug. Should this then be fixed in an ubuntu-specific patch for iso-codes?