Subject: [Ltru] Re: Updated draft-4646bis...

From: "Doug Ewell" <[email-masked]>
Date: Fri, 3 Aug 2007 06:58:21 -0700

Peter Constable <petercon at microsoft dot com> wrote:

> Wah!? Combining the variant tag fonipa with Kore shouldn't be valid, 
> though I guess we don't have a way to block it at present. (It would 
> take some awkward combination of  "must have script subtag Latn" OR 
> "must have a lang subtag with Suppress-Script of 'Latn'".)

Which is a place we really don't want to go.  "Tag content wisely" is 
the best way to prevent such tags.

But I would rather see a different language-script-region-variant 
combination that doesn't call quite so much attention to the ability to 
create semantically contradictory tags.  The passage is supposed to be 
about semantically consistent tags that refer to non-existent language 
variations.

--
Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14
http://users.adelphia.net/~dewell/
http://www1.ietf.org/html.charters/ltru-charter.html
http://www.alvestrand.no/mailman/listinfo/ietf-languages

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

---

From: Addison Phillips <[email-masked]>
Date: Fri, 03 Aug 2007 07:39:14 -0700

Doug mentioned:
 > The passage is supposed to be

I'm not sure that it is. The section is about "valid-yet-useless" tags, 
which includes, I assume, absurdities. I didn't want to create an 
absurdity by ignoring Prefix. Thus the "problem" (if you can call it 
that) is a dearth of generic variants.

We could use "tlh-Cyrl-AQ-fonupa", I suppose, or maybe 
"eu-Cyrl-SN-fonupa" (Basque, Cyrillic, Senegal, UPA transcription).

Addison

-- 
Addison Phillips
Globalization Architect -- Yahoo! Inc.
Chair -- W3C Internationalization Core WG

Internationalization is an architecture.
It is not a feature.

---

From: Peter Constable <[email-masked]>
Date: Fri, 3 Aug 2007 08:03:55 -0700

Arabic as used in Colombia written in Cyrillic is not an absurdity. It's perfectly reasonable; it just doesn't happen to be real.

But you do already have an absurdity: IPA transcription in Korean script: by definition, IPA must be in Latin script. (That's different from phonetic transcription in Korean script, which does exist, BTW.)

In your Klingon and Basque examples, the particular languages, script or regions used do not contribute to the absurdity, though some might wrongly perceive that to be the case. It is only the combination of fonupa with Cyrl that is absurd.

Peter

> -----Original Message-----
> From: Addison Phillips [mailto:[email-masked]]
> Sent: Friday, August 03, 2007 7:39 AM
> To: Doug Ewell
> Cc: LTRU Working Group
> Subject: Re: [Ltru] Re: Updated draft-4646bis...
>
> Doug mentioned:

---

From: [email-masked]
Date: Fri, 3 Aug 2007 13:40:48 -0700

All,

I need to update some tagging in a language list here at Sony Pictures. My 
current language requirement for Chinese languages is:

Audio Languages: Used for dubbing and original language content.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, PRC) = zh-cmn-CN
* Chinese (Mandarin, Taiwanese variant) = zh-cmn-TW
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

Text Languages: Used for localization of language other than the original 
language as well as captions and subtitles. Subtitles may also occur in an 
original version that features more than one language.

* Chinese (No other variant information known) = zh
* Chinese (Mandarin, Traditional) = zh-cmn-Hant
* Chinese (Mandarin, Simplified) = zh-cmn-Hans
* Chinese (Cantonese) = zh-yue
* Chinese (Taiwanese) = zh-min-nan

I'm not sure if we closed the discussion on whether "zh-cmn" or "cmn" will 
be preferred in RFC 4646bis. Of these tags, which are most likely to be 
deprecated in the new regime? It's unclear to me how I should code 
Mandarin, Cantonese, and Taiwanese if I want the best chance of being 
compatible with the preferred tagging to be determined by this committee 
at a later date. I thought this business scenario might help the 
discussion, if this issue is not resolved yet. I looked through the 
archive and it doesn't look like this issue is closed. To me, the "zh" in 
these tags (especially written language categories) seems helpful.

Regards,

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384
_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: [email-masked]
Date: Mon, 6 Aug 2007 12:04:15 -0700

Another practical question to consider in the new era.... I know Peter and 
I discussed this in the past, but I'm not sure if we raised the question 
to the rest of the group and it hasn't come up since 639-3 was published.

What should I do with films that have been categorized as Serbo-Croatian 
in the past? The language isn't suddenly different because the political 
climate changed since the films were first made. The distinction between 
Serbian and Croatian is not particularly significant in audio works, so we 
may not find it useful (from a business perspective) to do the research to 
make guesses as to whether any given film is more Serbian or Croatian. I 
am not talking about textual forms of the language -- only audio uses.

If I wish to maintain classifications previously made against this 
deprecated language that is now back in business in 639-3, would I extend 
the deprecated 639-1 prefix and include the 639-3 code; use one of the 
deprecated 639-2 codes; or just use the new 639-3 code alone? Which of 
these options is most "wise"?

I'm only considering this question in terms of spoken content and I 
realize we don't have the answer for this yet. But I figure answers start 
with questions (despite my studio's affiliation with "Jeopardy").

Regards,

Karen Broome

[email-masked] 
08/03/2007 01:40 PM

To
LTRU Working Group <[email-masked]>
cc

Subject
[Ltru] Question on variants

All, 

Regards, 

Karen Broome
Metadata Systems Designer
Sony Pictures Entertainment
310.244.4384 _______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Addison Phillips <[email-masked]>
Date: Mon, 06 Aug 2007 13:22:20 -0700

[email-masked] wrote:
> in the past? 

Nothing? Presumably these were also associated with the defunct region 
'YU' (also deprecated, but legal).

> The language isn't suddenly different because the political 

Whether you change it for cultural, political, or otherwise-motivated 
reasons is up to you. The original tags remain (and have always 
remained) valid. Here's the record in the registry:

%%
Type: language
Subtag: sh
Description: Serbo-Croatian
Added: 2005-10-16
Deprecated: 2000-02-18
%%

> these options is most "wise"?

Actually, Serbo-Croatian has never been "out of business". It is 
deprecated, but not illegal.

The proposal is that Serbian, Croatian, Bosnian, and Serbo-Croatian are 
all on the "same level" (as primary language subtags). The fact that 
there is a macrolangauge mapping from the three former to the latter is 
not important in language *tagging*, although it might be useful in your 
applications (for the reasons you give). None of the proposals for 
extlang would alter this situation (for stability reasons).

Addison