Subject: Re: New Last Call: 'Tags for Identifying Languages' to BCP

From: Bruce Lilly <[email-masked]>
Date: Sun, 12 Dec 2004 12:02:09 -0500

> Date: Sat, 11 Dec 2004 12:14:42 -0800
> From: "Randy Presuhn" <[email-masked]>
> Subject: Re: Ietf-languages Digest, Vol 24, Issue 5
> To: <[email-masked]>, <[email-masked]>
> Message-ID: <002f01c4dfbe$0d218f60$7f1afea9@oemcomputer>
> 
> Hi -
> 
> > From: "Bruce Lilly" <[email-masked]>
> > To: <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Friday, December 10, 2004 4:54 PM
> > Subject: Re: Ietf-languages Digest, Vol 24, Issue 5
> ...
> > Eliminating bilingual descriptions for the language,
> > country (and UN region) codes leaves implementors
> > in a quandary.
> ...
> 
> Huh?  These are language TAGS.  If, for some reason, some implementor
> thought it made sense to display one of these in a localized form (rather
> than just using them to determine what locale, etc. should be used in
> rendering some text) there's no requirement that the English-language
> country names that appear in the registration be used.

That's not the point. The point is that under RFC 3066,
the bilingual ISO language and country code lists are
considered definitive. An implementor can (and has)
therefore use those lists for (e.g.) providing users
with menus (in either language) from which a language
or country code may be selected.  By declaring the ISO
lists no longer definitive, and by providing only
English descriptions of the codes in the proposed
revised registry which would be used instead of the ISO
lists, the draft proposal deprives implementors of
being able to provide that functionality (viz. an
official description in French of codes).

> Indeed, a UI 
> could just as well draw a map as display a name.

That would be awfully difficult for a character-based
UI, and would not be useful for language codes. Nor
would it be helpful for users who lack map-reading
skills, but who recognize "Allemagne" when they see it.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Sam Hartman <[email-masked]>
Date: Sun, 12 Dec 2004 14:49:27 -0500

>>>>> "Bruce" == Bruce Lilly <[email-masked]> writes:

    >> Date: Sat, 11 Dec 2004 12:14:42 -0800 From: "Randy Presuhn"
    >> <[email-masked]> Subject: Re: Ietf-languages
    >> Digest, Vol 24, Issue 5 To: <[email-masked]>,
    >> <[email-masked]> Message-ID:
    >> <002f01c4dfbe$0d218f60$7f1afea9@oemcomputer>
    >> 
    >> Hi -
    >> 
    >> > From: "Bruce Lilly" <[email-masked]> > To:
    >> <[email-masked]> > Cc: <[email-masked]> > Sent:
    >> Friday, December 10, 2004 4:54 PM > Subject: Re: Ietf-languages
    >> Digest, Vol 24, Issue 5 ...  > Eliminating bilingual
    >> descriptions for the language, > country (and UN region) codes
    >> leaves implementors > in a quandary.  ...
    >> 
    >> Huh?  These are language TAGS.  If, for some reason, some
    >> implementor thought it made sense to display one of these in a
    >> localized form (rather than just using them to determine what
    >> locale, etc. should be used in rendering some text) there's no
    >> requirement that the English-language country names that appear
    >> in the registration be used.

    Bruce> That's not the point. The point is that under RFC 3066, the
    Bruce> bilingual ISO language and country code lists are
    Bruce> considered definitive. An implementor can (and has)
    Bruce> therefore use those lists for (e.g.) providing users with
    Bruce> menus (in either language) from which a language or country
    Bruce> code may be selected.  By declaring the ISO lists no longer
    Bruce> definitive, and by providing only English descriptions of
    Bruce> the codes in the proposed revised registry which would be
    Bruce> used instead of the ISO lists, the draft proposal deprives
    Bruce> implementors of being able to provide that functionality
    Bruce> (viz. an official description in French of codes).

Programming lore has the rule of zero, one or infinity; it goes by
many other names but the concept is in part that by the time you need
more than one of something, you'll probably need a lot of that thing.

Language descriptions seem to fit this rule fairly well.  By the time
we need to support multilingual language descriptions, we'll need more
than just English and French.

That means implementers today already have to deal with the fact that
they only have some of the language descriptions they need from
definitive standards.  They will already have to get descriptions for
other languages.

Since they are already using non-definitive language descriptions,
implementers can feel free to take the French descriptions from the
ISO standard for the many cases where the IANA registry and ISO
standard overlap.

Why is two definitive languages better than one definitive language
and one set of descriptions from an ISO standard?

--Sam