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

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