Subject: RE: [Ltru] Re: Moving Forward

From: "Addison Phillips" <[email-masked]>
Date: Wed, 13 Apr 2005 15:44:42 -0700

Interlinear below.

Addison

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

Internationalization is not a feature.
It is an architecture. 

> 
> Could we make this strong enough to spell out conditions when script
> subtags
> MUST NOT be used in tagging information, and to find a way to represent
> these conditions in registry entries?  This could take the form of some
> additional fine-tuning to the description of "Associated_Script", and
> might
> need an additional field.
[Addison Phillips] 

How about:

Subtags which are not important for distinguishing content in an application SHOULD NOT be used to form language tags. In particular, you MUST NOT use the script subtag unless (a) the language subtag has an Expected_Script field or (b) the specific script distinction is important to the application. For example, the tag "en-Latn-US" should be used exceedingly rarely since nearly all English texts are written in the Latin script and it is generally not important to filter out those few that are not, while documents that use the primary language subtag 'sr' (Serbian) must be distinguished by the choice of Latin or Cyrillic script.

> 
> Examples of how it sounds like we want things to work:
>     English & its varieties stay naked when latin, gets a -Brai when
> needed
>     Vietnamese & its varieties stay naked when latin, marked when no^m,
>     Mongolian and its varieties are always marked for script
>     Gothic is naked when in latin transcription, marked when in its
> historic alphabet
> 

[Addison Phillips] 

Vietnamese or English might take a Latn subtag in cases where that distinguishes between two choices in a document (en-Latn vs. en-Brai in a stylesheet, for example)

> 
> Agreed, but the extent to which these inadequate algorithms are
> implemented
> in existing software, we as a WG need to be very conscious and
> conscientious
> about which scenarios will and won't work in a net populated with new and
> old
> applications, as well as new and old data.  In cases where we don't give
> MUST/MUST not rules, we need to be sure that our guidance is very clear.
> If not following a SHOULD causes things to *break*, then "SHOULD" isn't
> strong enough.
[Addison Phillips] 

Yes, but MUST is very strong. The problem stems in many but not all cases from mixing with and without subtag usages together. Forbidding en-Latn-* from ever occurring causes problems when you do get a script subtag later and use RFR matching.

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

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Thu, 14 Apr 2005 02:05:34 +0200

On 00:44 14/04/2005, Addison Phillips said:
>Subtags which are not important for distinguishing content in an 
>application SHOULD NOT be used to form language tags. In particular, you 
>MUST NOT use the script subtag unless (a) the language subtag has an 
>Expected_Script field or (b) the specific script distinction is important 
>to the application. For example, the tag "en-Latn-US" should be used 
>exceedingly rarely since nearly all English texts are written in the Latin 
>script and it is generally not important to filter out those few that are 
>not, while documents that use the primary language subtag 'sr' (Serbian) 
>must be distinguished by the choice of Latin or Cyrillic script.

Even me, I understand what you mean. But I am afraid it does not make a 
difference for a parser developer? The parser is a piece of logic, not of 
comparative information. That something only occurs one time, or even 
should not occur or all the time: it must be supported? Or am I wrong?

To respond your question.

1. you are stuck with an XML design bundling bug. You try to make a 
feature. I think you should make it a temporary feature (to assume legacy 
and transition) and to fix the bug. Please consider that even if _you_ 
think genuinely it is a feature, the experience of this tiny WG already 
shows various ways to understand it: you will never prevent developpers to 
workout "better" solutions (a one to one, tag/parameter, approach will 
always be considered as more flexible). Unless you have a very strong 
documented rationale to bundle langtag's elements and the cacapcity to 
preach to developers, you _are_ eventually to support langtag, scriptag, 
countrytag, etc..

2. For your XML bundling bug: your 2-4-2 tag seems a well conceived 
temporary patch which will work until you have given XML the extensibility 
it needs. Unbundling, free format.

3. your solution should be part of the second document. The general 
guidelines to structure application oriented formats should be discussed in 
the first documen, with other language tag framework issues. The responses 
given to Ira shows the direact relation between the tag format and the filter.

jfc