[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltru] 639-5 (was RE: ISO 639 language code addition rules...)



 
Phillips, Addison wrote:
> 
> I generally agree with the idea that having some of this 
> ancillary information in the registry would be useful. 
> However, the 'Type' field isn't the way to do this. The 
> 'Type' field indicates what kind of subtag it is.
> 
> Instead, I would suggest that we include some more 
> meta-information in specific fields in the registry. For 
> example, we could have a 'Source' field to indicate where a 
> record came from and an Attribute field for derived 
> attributes. Here's what our record collection might contain:
> 
> Type: language | extlang | script | region | variant | grandfathered | redundant

Well, I still hope that the extlang stuff is not really coming back...

> Subtag | Tag: <value>
> Added: <date>
> Deprecated: <date>
> Prefix: <value>
> Suppress-Script: <value>
> Description: <text>
> Source: ISO639-1 | ISO639-2 | ISO639-3 | ISO639-5 | ISO3166-1 | ISO15924 | registration

ISO639-2 would be retargeted (per "Type: language" subtag) as either ISO639-3
or ISO639-5 now, would they not? Given that, IIUC, the codes in ISO 639-2 by
necessity are also registered as ISO 639-3 or ISO 639-5 codes, and LTRU II are
retargeting from ISO 639-2 to ISO 639-3 and (hopefully also) ISO 639-5.

UNM49 (or similar "source code") should be there too, should it not?

> Attribute: macrolanguage | collection | ...

Maybe "Kind: individual | macrolanguage | collection" (required for "Type:
language", not allowed for other "Type"s. I would not recommend anything
similar for, say, region codes. Nit: And move it up to just after "Type". 


		/kent k

_______________________________________________
Ltru mailing list
Ltru at ietf.org
https://www.ietf.org/mailman/listinfo/ltru



Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.