Re: [Ltru] Changes to draft-4645bis resulting from new draft-4646bis

["Mark Davis" <mark.davis at icu-project.org>]

Mark

On Mon, Jul 21, 2008 at 2:45 PM, Phillips, Addison <addison at amazon.com> wrote:

                                                                          

<t>Records other than those of type 'extlang' that contain a 'Preferred-Value' field MUST also have a 'Deprecated' field. This field contains the date on which the tag or subtag was deprecated in favor of the preferred value.</t><t>For records of type 'extlang', the 'Preferred-Value' field appears without a corresponding 'Deprecated' field. An implementation MAY ignore these preferred value mappings, although if it ignores the mapping, it SHOULD do so consistently. It SHOULD also treat the Preferred-Value as equivalent to the mapped item. For example, the tags "zh-yue-Hant-HK" and "yue-Hant-HK" are semantically equivalent and ought to be treated as if they were the same tag.</t>

all good (we could make the first MUST be a SHOULD, but I'm ok with your text).

 

AP> We could do that, but it would be a change in the rules. That is, we don't now allow a value to have a preferred value unless we mean to deprecate it. Other than the extlang case (which I regard as handwaving), are there any cases in which we would have a P-V without also deprecating the non-preferred value?

I'm ok with your text (my reservations are minor; and I don't want to make an issue of them).

 

[in 3.1.9.  Suppress-Script Field]
ADD AT END
Tags formed using extlangs are equivalent to those with the extlang subtag as the primary language subtag; thus the Suppress-Script field for the primary language subtag applies to tags using the corresponding extlang. For example, if 'abh' has Suppress-Script: Arab, then Arb should be suppressed from both ar-abh-AF and abh-AF.

 

(editor hat OFF) Wouldn't we just include the S-S field in the records of type extlang?

Because they there is always the chance that we screw up the synchronization.  If we include the S-S by reference that can't happen. If we include the SS field in extlang fields, then we also have to add the rule for the Language Reviewer that anything that every extlang MUST have an SS if and only if the corresponding primary language subtag does.

 

AP> And, just to make trouble, can an extlang have a different S-S from its Macrolanguage??

There is nothing fundamental about the relationship that requires the same scripts. 'sr' and 'hr' share the same macrolanguage, but don't have the same default script.

 

And can an extlang have an S-S and its macrolanguage not have one.

Clearly yes.
 

For example, could 'gan' have an S-S of Hans even though zh does not (and should not)?

Yes.

Maybe we should go the other direction and inherit from Macrolanguage.

No. We should impose all and only those conditions that are required. And the required condition is that "zh-yue" and "yue", being equivalent, need to have the same SS. If we make the SS of the corresponding primary language subtag apply to the entlang, then we don't have the possibility of mismatches in the repository. But I send you possible language if you (and others) really want it in there.

 

 

Addison

 

 

Addison Phillips

Globalization Architect -- Lab126

 

Internationalization is not a feature.

It is an architecture.

 

 

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