Subject: RE: [Ltru] Re: Preparations for smart matching

From: "Peter Constable" <[email-masked]>
Date: Tue, 22 Mar 2005 08:37:46 -0800

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Frank Ellermann
> Sent: Saturday, March 19, 2005 8:09 PM

> Could we rename "recommended_prefix" to "associated_tag", or
> something in this direction ?  Then the 6th column of languages
> would be free for a pointer to a default script.

A couple of issues: it would not be a trivial task to populate that
field in a reasonably accurate way for all languages, and you'd need to
allow for cases in which a language is written in several scripts no one
of which has a greatest claim to being the default.

> At the moment the draft says:
> 
> | The "recommended_prefix" field is empty, except where the
> | type is "variant"
> 
> That could be changed to e.g.
> 
>   The "recommended_prefix" is generally empty.  In the case of
>   a "variant" it's often the recommended "language" prefix, but
>   could be also a language-script, language-script-region, or
>   language-region prefix.

That's an interesting suggestion worth some thought.

>   For the type "language" this field can be used to define a
>   default "script" for the correspoding "laguage", and then the
>   resulting tag or prefix language-sript is NOT RECOMMENDED.

Ah! You'd use this to indicate a default script for cases in which there
is one that is predominant. A better suggestion than what I thought you
had in mind. Note, though, that there will be gray areas: 99.99% of all
en content is in the common Latin orthography rather than other writing
systems, such as IPA or Gregg Shorthand; it's clear we'd consider Latn
the default in such a case. What if the proportion were 95%? 90%? 85%?
...  What's the threshold at which we begin to assume a default?

> > Thus if you want to match "en-Latn-US-boont" with "en-boont",
> > it is enough to disassemble both tags and observe that all
> > the subtags in the second tag are also present in the first.
> 
> That's IMFO not good enough.  If a client offers en-boont and
> en-misc (script "misc"), and the server has en-misc-US-boont,
> then the client should try en-misc, but not en-boont.
> 
> Because "misc" is probably very important, if it's not "Latn"
> as in the default for en.
> 
> > If "en-Latn-US-boont" is a match for "en-boont", then so is
> > "en-Ogam-MV-boont".
> 
> Unless you have en-Ogam, then you need to know the default
> script for en (which isn't Ogam).

Hang on. It's unclear what you're comparing. You need to start
qualifying the argument structure here: you're comparing two tags: one
is the what is being requested, the other is the attribute of the
resource in the repository. You've got to specify which is which.

If the request is for "en-boont", then "en-Ogam" in the repository
should not be a match (except in a fallback situation, when you must
return something, haven't found a match and are looking for the best
available alternative -- e.g. software UI resource loading). That's not
because the script isn't Latn; it's because the request was specifically
for Boontling, and "en-Ogam" is not constrained to that.

If the request is for "en-boont", then ideally you'd want
"en-Latn-US-boont" (if that were actually used) in the repository to be
a match.

Peter Constable

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

---

From: Frank Ellermann <[email-masked]>
Date: Wed, 23 Mar 2005 09:27:19 +0100

Peter Constable wrote:

 ["associated_tag"]
> A couple of issues: it would not be a trivial task to
> populate that field in a reasonably accurate way for all
> languages

Yes, where it's not trivial don't try it.

> What if the proportion were 95%? 90%? 85%? ...  What's the
> threshold at which we begin to assume a default?

Anything below "99%" (defined as "almost all today") doesn't
qualify as an obvious or trivial default.   It could be still
hard to decide this for cases like sr, but OTOH the job of a
tag reviewer should be more than copying various ISO sources
into a communal IANA registry.  [[ That could be even an IPR
or copyright issue - IANAL but paranoid. ]]

 [en-Ogam-US-boont]
> If the request is for "en-boont", then "en-Ogam" in the
> repository should not be a match

Sure, the request was for en-Ogam-US-boont or en-Ogam-boont,
and the server offers only en-Ogam or en-boont.  Or it only
offers en-Ogam-US or en-US-boont - that's a better example,
because it challenges any simple matching strategy.

So should it "know" (assume) that en-boont is most probably
en-Latn-boont ?  If yes it needs a default.  But Doug found
queries where a default is misleading, and the best way to
bypass this problem is to add a script everywhere.  Which is
not the best solution for 3066-software, but OTOH potential
problems of 3066-software with en-boont are irrelevant.

If the alternative is "no default, add Latn everywhere", the
real problem with 3066 software are cases like en-GB, asking
for en-Latn-GB won't match en-GB with legacy software.

And vice versa, if I create a new document I'm trapped, either
I say en-Latn-GB or en-GB.  The former is a problem for legacy
software, the latter is vague for new software, could it mean
en-Ogam-GB ?
              Bye, Frank