+1 Thanks for some good clear thought for a change. I agree that I hated this counting the field members approach. Cheers, - Ira Ira McDonald (Musician / Software Architect) Blue Roof Music / High North Inc PO Box 221 Grand Marais, MI 49839 phone: +1-906-494-2434 email: imcdonald at sharplabs.com > -----Original Message----- > From: ltru-bounces at lists.ietf.org > [mailto:ltru-bounces at lists.ietf.org]On > Behalf Of Addison Phillips > Sent: Friday, April 15, 2005 3:27 PM > To: Addison Phillips; Randy Presuhn; ltru at ietf.org > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > One more thought. > > Maybe we're trying to fix this the wrong way. Solutions that > rely on counting the number of script fields produce problems > because what you do is unstable and based on how many times a > language has had a script registered. > > Instead, we should create fields that exactly match what you > do with them. > > Subtag: en > Suppress_Script: Latn > > Subtag: sr > Require_Script: Cyrl, Latn > > Subtag: got > Suppress_Script: Latn, Goth > Comment: only an example > > With these rules: > > 1. Script subtags listed in the 'Suppress_Script' field > SHOULD NOT be used to form language tags unless they add > specific information to the language tag required by an application. > > 2. Script subtags listed in the 'Require_Script' field SHOULD > always be used to form language tags when the script used by > the content being identified matches the script unless there > is a specific reason to omit the script subtag in the application. > > 3. If the script of the content matches neither field (or the > fields are both unpopulated), the script subtag SHOULD NOT be > used to form language tags for that language unless it adds > specific information to the language tag which is required by > the application. > > Suppress_Script is NOT guaranteed to be stable (values may be > removed). Require_Script IS guaranteed to be stable (values > can be added only). The two fields are mutually exclusive. > > 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: ltru-bounces at lists.ietf.org > [mailto:ltru-bounces at lists.ietf.org] On > > Behalf Of Addison Phillips > > Sent: vendredi 15 avril 2005 10:11 > > To: Randy Presuhn; ltru at ietf.org > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > > I agree that the Gothic example might not be obvious, this > would be a good > > place to put a comment into the registry. > > > > It might be useful to actually distinguish between > processing language and > > content language (metadata). For example, one might use > "got-Latn" and > > "got-Goth" on <p> elements in an XHMTL document so that > appropriate fonts > > can by applied to each in a stylesheet and still use "got" > (meaning "got- > > Latn") in the <meta> element or in external references to > the document. > > See: > http://www.w3.org/TR/i18n-html-tech-lang/#ri20030510.102829377, which > > helped form my thinking about this. > > > > I don't think that script associations need to pass an > obviousness test. > > But the temptation to register every script a language has ever been > > written in should be guarded against since it will cause a > lot of texts to > > pick up "SHOULD" when they really should not. Perhaps > having separate > > fields (default and associated/expected) would help this, allowing > > promiscuous registration of associated scripts. > > > > In that case, it is: > > > > 0*1[default_script] = SHOULD NOT > > 2*[default_script] = SHOULD always > > [associated_script] = informational list of additional scripts??? > > > > Comments? > > > > 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: ltru-bounces at lists.ietf.org > [mailto:ltru-bounces at lists.ietf.org] > > On > > > Behalf Of Randy Presuhn > > > Sent: jeudi 14 avril 2005 19:32 > > > To: ltru at ietf.org > > > Subject: Re: [Ltru] Re: Proposed Text for Moving Forward > > > > > > Hi - > > > > > > > From: "Addison Phillips" <addison.phillips at quest.com> > > > > To: "Frank Ellermann" <nobody at xyzzy.claranet.de>; > <ltru at ietf.org> > > > > Sent: Thursday, April 14, 2005 4:48 PM > > > > Subject: RE: [Ltru] Re: Proposed Text for Moving Forward > > > ... > > > > Perhaps the rules should be: > > > > > > > > 1. If the primary language has no associated script, > > > > you SHOULD NOT use a script subtag > > > > unless it adds distinguishing information for that context. > > > > > > > > 2. If the primary language has a single associated script > > > > and the content uses that script, > > > > you SHOULD NOT use the script subtag (unless etc.). > > > > > > > > 3. If the primary language has two or more associated scripts > > > > and the content uses one of them, > > > > you SHOULD use the script subtag (unless it is harmful > to do so). > > > > > > > > 4. If the primary language has any number of associated scripts, > > > > but the content uses a different script, > > > > you SHOULD use the script subtag (unless it is harmful > to do so). > > > > > > To get the desired results for Gothic, (no subtag for > Gothic transcribed > > > into latin alphabet, subtag required if using the > historical Gothic > > > alphabet) > > > I think this would mean that the entry for Gothic could > not identify > > > Gothic > > > as an associated script, and that the associated script > (if any) would > > be > > > latin. I guess this works, but I'd classify it as > "obvious only if > > > previously > > > understood." > > > > > > Randy > > > > > > > > > > > > > > > _______________________________________________ > > > Ltru mailing list > > > Ltru at lists.ietf.org > > > https://www1.ietf.org/mailman/listinfo/ltru > > > > > > _______________________________________________ > > Ltru mailing list > > Ltru at lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/ltru > > > _______________________________________________ > Ltru mailing list > Ltru at lists.ietf.org > https://www1.ietf.org/mailman/listinfo/ltru > _______________________________________________ Ltru mailing list Ltru at lists.ietf.org https://www1.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.