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

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



I agree... except to note that Suppress-Script is not a normative field. It is an informative field. Lack of a Suppress-Script does not imply that a script subtag is needed or necessary. It may only imply that specific information is not available for that language.

If one knows that the majority of Arabic-language documents are written in the Arabic script and knows nothing about Sudanese Creole Arabic (pqa), one still might not wish to include the 'Arab' subtag in a tag "ar-pqa-SD".

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.


> -----Original Message-----
> From: ltru-bounces at ietf.org [mailto:ltru-bounces at ietf.org] On
> Behalf Of Kent Karlsson
> Sent: Tuesday, July 22, 2008 5:01 AM
> To: 'LTRU Working Group'
> Subject: Re: [Ltru] Changes to draft-4645bis resulting from new
> draft-4646bis
>
> Doug Ewell wrote:
> > A primary-extlang combination should take its Suppress-Script,
> > if any, from the primary language subtag.
>
> For zzz-xxx and xxx to be as equivalent as possible
> (and I think that is a goal), zzz-xxx must not only
> take the supress-script from the xxx subtag (as a
> language subtag, it seems unnecessary to duplicate
> this information in the record for xxx as extlang).
> It must even be so that the the supress-script from
> xxx, ***including its absence*** MUST ***override***
> the supress-script from zzz in the zzz-xxx combiniation.
> So in zzz-xxx the supress-script from the record for
> zzz is NEVER relevant.
>
>                 /kent k
>
> _______________________________________________
> Ltru mailing list
> Ltru at ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
_______________________________________________
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.