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

[[e-mail]]

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 <[e-mail]> 
10/10/2007 11:02 AM

To
Mark Davis <[e-mail]>, Addison Phillips 
<[e-mail]>
cc
"[e-mail]" <[e-mail]>
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
[e-mail]
https://www1.ietf.org/mailman/listinfo/ltru

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