Subject: [Ltru] using 'und' for default content

From: "Addison Phillips" <[email-masked]>
Date: Fri, 18 Nov 2005 14:41:38 -0800

> >>
> >>=>
> >>[reword for clarity. Funny thing: when I first read 'might be content
> >>with no language tag' I read it as the verb "be content with", like "be
> >>happy with". The empty tag is not a valid language tag, so we should say
> >>"und", then say that a system can use alternatives. Here is the text.]
> >>
> >>
> >[Addison Phillips]
> >
> >No, not 'und' (and I *hate* 'und'). 'Und' would be an example of an
> implementation specific decision. Personally I would prefer never to see
> 'und' content being used as a default.
> >
> >
> Well, "" is illegal as a language-tag, so I was just using it as a
> stand-in because we don't have a language tag for "root".

We have perfectly good text describing the default content, I think. It is implementation defined. It might be in some predetermined language, or it might be unlabeled or it must be whatever. But it definitely should not be 'und'. We should strongly discourage the use of 'und' and 'mul', IMHO.

We don't need to complicate this particular point too much, I think, by introducing all the options.

> 
> >>When performing lookup using a language priority list, the progressive
> >>search MUST consider each language range before finding the default. The
> >>default might be specified as "und" (or be indicated with an empty
> >>value, as with xml:lang in the XML specification, or with "root" as in
> >>some systems), or it might be specified as a particular language range.
> >>This language range is thus treated as if it were appended to the end of
> >>the language priority list, rather than after each item in the language
> >>priority list.
> >>
> >>
> >[Addison Phillips]
> >
> >I prefer not to make this change. I think it delves too closely into the
> implementation specific.
> >
> >
> It can't be left as it is. Other alternatives?

Why not? Here, for reference, is what it says:

--
When performing lookup using a language priority list, the progressive search MUST proceed to consider each language range before finding the default content or empty tag. The default content might be content with no language tag (or with an empty value, as with xml:lang in the XML specification), or it might be a particular language designated for that bit of content.

One common way to provide for default content is to allow a specific language range to be set as the default for a specific type of request. This language range is then treated as if it were appended to the end of the language priority list, rather than after each item in the language priority list.
--

I don't see why your version is any different, except that it introduces 'und'. Note that "content with no language tag" is not the same as "content with the (illegal) language tag (empty string)".

Addison P. Phillips
Globalization Architect, Quest Software

Internationalization is not a feature.
It is an architecture. 

> -----Original Message-----
> From: Mark Davis [mailto:[email-masked]]
> Sent: 2005年11月18日 13:42
> To: Addison Phillips
> Cc: [email-masked]
> Subject: Re: [Ltru] draft-06 comments: choice of range
> 
> 
> 
> >>----
> >>
> >>5. (return default content)
> >>a. ja-JP
> >>b. ja
> >>c. (empty tag or other default content)
> >>
> >>5. (default)
> >>a. ja-JP
> >>b. ja
> >>c. und
> >>
> >>
> >[Addison Phillips]
> >
> >How about:
> >
> >5. (default content lookup)
> >   a. ja-JP
> >   b. ja
> >   c. (implementation defined)
> >
> >
> That works.
> 
> >>----
> >>
> >>Wildcard values in an extended language range are supposed to match any
> >>value
> >>=>
> >>Wildcard values in an extended language range match any value
> >>
> >>
> >[Addison Phillips]
> >
> >No, they are *supposed* to match, but in this case they don't. They match
> the empty value.
> >
> >
> I read that differently. When you say "supposed to match", it sounds
> like there is a choice, that there are some values that they don't
> match. Like the US is "supposed to" disallow torture.
> 
> >>----
> >>
> >>Add
> >>
> >>
> >>      3.3.x. Distance Metric Lookup
> >>
> >>Distance metric lookup is performed by producing an ordered list of
> >>filtered results as specified in 3.2.2, then returning the first item.
> >>
> >>
> >[Addison Phillips]
> >
> >I think we'd best not go down that path. Among other things: it won't
> work. Distance metric filtering can produce items with identical scores...
> >
> >
> Ok, drop it.
> 
> >
> >
> >>----
> >>
> >>Mark
> >>
> >>P.S. I still think that the extended range lookup doesn't quite work,
> >>but I'll send that in a separate message.
> >>
> >>
> >[Addison Phillips]
> >
> >No, it doesn't work and we eliminated it. We've mapped extended ranges
> onto basic ranges, which do work, producing different results than the
> language priority list might lead one to expect.
> >
> >
> Let me look this over again.

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