RE: [Ltru] Extended language tags (long reply)

http://www.ethnologue.com/show_language.asp?code=vls

"Flemish" is listed as an alternate name in Netherlands and France.

Karen Broome

Peter Constable <petercon@microsoft.com> wrote on 10/10/2007 11:46:33 AM:

> Where do you see "Flemish" cited as synonymous with "Vlaams"?
> 
> The closest I see is a statement that Dutch is "[c]alled 'Vlaams' in
> Belgium, even though it is different from the (West) Vlaams spoken 
there."
> 
> 
> Peter
> 
> > -----Original Message-----
> > From: Karen_Broome@spe.sony.com [mailto:Karen_Broome@spe.sony.com]
> > Sent: Wednesday, October 10, 2007 11:37 AM
> > To: ltru@ietf.org
> > Subject: RE: [Ltru] Extended language tags (long reply)
> >
> > I wrote:
> >
> > (I still don't know whether "vls"
> > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a
> > synonym for Vlaams in 639-3.)
> >
> > Sorry, I meant to say that "Flemish" is cited as a synonym on
> > Ethnologue.com.
> >
> > Karen Broome
> >
> >
> >
> >
> > Karen_Broome@spe.sony.com
> > 10/10/2007 11:25 AM
> >
> > To
> > Shawn Steele <Shawn.Steele@microsoft.com>
> > cc
> > "ltru@ietf.org" <ltru@ietf.org>
> > Subject
> > RE: [Ltru] Extended language tags (long reply)
> >
> >
> >
> >
> >
> >
> > I think if meaningful fallback is the goal, you need to consider both
> > audio and textual forms of languages and their respective fallback
> > mechanisms. While a fallback to "zh" (from "zh-cmn" or "zh-HK", etc.)
> > would likely be useful in written contexts, falling back to spoken 
"zh"
> > from spoken "cmn" may provide something unintelligible.
> >
> > In the context of my industry, it would likely be useful for a
> > Cantonese
> > speaker to be able to find subtitled films in "zh" if "zh-yue" is not
> > available. Obviously there are questions of simplified vs. traditional
> > orthography, but the "zh" tag alone encompasses both orthographies. 
But
> > if
> >
> > the Cantonese speaker is looking at dubbed films, a fallback to spoken
> > "zh-cmn" is not as likely to be useful.
> >
> > >From what I understand the same is true in written Dutch vs. spoken
> > Flemish -- a Flemish speaker may be able to easily read standard 
Dutch,
> > but the spoken forms can create problems of understanding to the point
> > where Dutch is subtitled in Belgium. (I still don't know whether "vls"
> > (639-3) falls back to "nld/dut" in 639-2, though Flemish is cited as a
> > synonym for Vlaams in 639-3.)
> >
> > Please consider the nature of both audio and written language with
> > respect
> >
> > to ext langs. I think you'll find what makes sense for fallback 
depends
> > on
> >
> > these distinctions in many other cases than those I've mentioned.
> >
> > Regards,
> >
> > Karen Broome
> > Metadata Systems Designer
> > Sony Pictures Entertainment
> > 310.244.4384
> >
> >
> >
> > Shawn Steele <Shawn.Steele@microsoft.com>
> > 10/10/2007 11:02 AM
> >
> > To
> > Mark Davis <mark.davis@icu-project.org>, Addison Phillips
> > <addison@yahoo-inc.com>
> > cc
> > "ltru@ietf.org" <ltru@ietf.org>
> > Subject
> > RE: [Ltru] Extended language tags (long reply)
> >
> >
> >
> >
> >
> >
> > ================
> >
> > What we don't want to do is make recommendations that if implemented,
> > are
> > harder for people to control and get the right answer. And baking
> > extlang
> > into the tags is even worse -- since it introduces backwards
> > incompatibilities that require old code to be modified to work around.
> >
> > ================
> >
> > cmn is completely incompatible with existing practice anyway, so you
> > can?t
> >
> > claim that it solves the problem.  Existing clients ask for zh-HK (or
> > whatever) and code is tagged as zh-HK (or whatever).  Those won?t 
match
> > cmn using RFC 4647.
> >
> > So for backwards compatibility zh-cmn is no worse than cmn.  And if 
you
> > don?t like the inference of the zh, then you can ignore that part, but
> > at
> > least the data?s there if people do want it.
> >
> > For some macro languages the strict fallback is probably 
inappropriate,
> > however I don?t expect to find matches in that case (because I don?t
> > expect correctly tagged data to be ?zh?).  If this is a concern, those
> > are
> >
> > easily filtered out.
> >
> > >From the discussion I don?t think the bigger problem is whether or 
not
> > we
> > go with zh-cmn or just cmn.  The bigger issue seems to be how to 
modify
> > RFC 4647 to provide meaningful fallback with whichever mode is used.
> > Since some applications may (or may not) want to consider zh-HK or
> > other
> > legacy behaviors, such recommendations aren?t trivial.  Given the
> > differing requirements amongst us, I suspect a certain flexibility of
> > the
> > applications will be necessary, perhaps several suggestions rather 
than
> > the strict behavior of RFC 4647 (which everyone seems to modify for
> > their
> > purposes anyway)
> >
> > - Shawn_______________________________________________
> > Ltru mailing list
> > Ltru@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> >
> >
> >
> >
> >
> > _______________________________________________
> > Ltru mailing list
> > Ltru@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ltru
> 
> 
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www1.ietf.org/mailman/listinfo/ltru
> 

_______________________________________________
Ltru mailing list
Ltru@ietf.org
https://www1.ietf.org/mailman/listinfo/ltru