Subject: RE: [Ltru] [psg.com #1018] Add Macro-Language field

From: "Addison Phillips" <[email-masked]>
Date: Wed, 1 Jun 2005 17:25:54 -0700

To the extent it makes sense to define the fields that will occur in the registry and define the structure and semantics of language tags now, we should do take care of defining the fields associated with extlangs. But I agree that we should stop making policy now for things that will be better defined later.

For me the substantive issue that must be dealt with is whether a limit of three, as opposed to five, extlangs can be sufficient (and avoid having a weird "minimum" required buffer size) [yes, Randy, issue #965]. Is there any reasonable likelihood that a five-fold macrolanguage "enclosing" would ever exist (requiring four extlangs and a primary language)?

The other point is: if we agree to change the term 'recommended-prefix' to 'required-prefix', this adds a small new requirement to validating processors (i.e. those that have a copy of the registry), while giving us a general purpose mechanism for handling prefixes?that will be understood "out of the box" when extlangs are assigned. I would submit that the effect of this is small now, since there are exactly two validating processors today that I'm aware of: Doug's and mine. And the benefit of it later is potentially large (since by then we hope there are many such processors).

Another way to say that is: extlangs have normative 'recommended-prefixes' assigned by ISO 639-3. Variant 'recommended-prefixes' are not externally maintained and thus must be assigned by ietf-languages and the registration process. Primary languages, regions and scripts cannot require a prefix by their very nature. Using the same mechanism allows a certain generalization in code that will make it easier to write a validating processor.

Addison

Addison P. Phillips
Globalization Architect, Quest Software
Chair, W3C Internationalization Core Working Group

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Peter Constable
> Sent: mercredi 1 juin 2005 16:34
> To: [email-masked]
> Subject: RE: [Ltru] [psg.com #1018] Add Macro-Language field
> 
> What will be true for macrolanguages that would not be true of any other
> potential 'require-prefix' case is that the macrolanguage relationship
> would be defined normatively in ISO 639-3. That is, ISO 639-3 will
> specify that a macrolanguage ID such as zap encompasses IDs zaq, zpo...
> which will be the basis for determining that zap is a required prefix
> for zaq, etc. Hence, I'm somewhat inclined to make a field in the
> registry specific to this.
> 
> But I'm not sure why we need to resolve this now. I'd rather focus on
> resolving any remaining issues that block completion of 3066*bis*.
> 
> 
> 
> Peter Constable
> 
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ltru

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

---

From: Frank Ellermann <[email-masked]>
Date: Thu, 02 Jun 2005 03:40:15 +0200

Addison Phillips wrote:
 
> if we agree to change the term 'recommended-prefix' to
> 'required-prefix', this adds a small new requirement to
> validating processors (i.e. those that have a copy of the
> registry), while giving us a general purpose mechanism for
> handling prefixes?that will be understood "out of the box"
> when extlangs are assigned.

If that's at all possible I'd like it very much.  Bye, Frank