Re: [Ltru] Proposed -t0- subtag

Note that I retitled, since it is drifting away from the original topic.

===

The distinctions in tagging content that can easily be made within BCP47* as
currently constituted* are:

   1. *Written content* (in a particular script: "uz-Latn", "uz-Arab", etc.)
   2. *Non-Written content* (eg "uz-Zxxx")
   3. *Either Written or Non-Written content* (eg "uz")
   4. *Both Written and Non-Written content* ("uz-Latn, uz-Zxxx", using
   language list)

Some distinctions that are not possible to make are:

   1. *Spoken content* (excluding other non-written content like "sung
   content", "telepathic content", etc.)
   2. *Both Spoken and Written content* (eg captioned video with audio,
   excluding sung content, etc)

One on the edge would be:

   1. *Written content* (unspecified script: Zyyy would probably serve fine
   for this)

The question is whether the first four are sufficient, and if not, whether
the extra work of doing an extension is necessary, or whether the
distinctions can be handled via variants (the simpler route).

Mark
*— Il meglio è l’inimico del bene —*

On Mon, Jul 25, 2011 at 11:09, Broome, Karen <Karen.Broome@am.sony.com>wrote:

> Well, I had considered registering a singleton on behalf of the Society of
> Motion Pictures and Television Engineers -- the xml:lang compliant tags are
> now specified in many, if not most, new industry standards. (Things are
> certainly still in transition from older ISO 639 classifications.) But SMPTE
> might benefit from more motion picture specific values (possible values:
> original, dubbed, captioned, subtitled, audio description).
>
> But I also wonder about the general utility of this and hadn't really
> broached the subject of "tone" or had an immediate need for something like
> that. It's interesting, but I think maybe it goes beyond language
> identification into aspects of the delivery and content. Fun stuff to work
> on, but not sure I need it now. But I think "spoken" and "written" are two
> distinctions that definitely help identify the "language". I realize this is
> a somewhat controversial belief.
>
> Regards,
>
> Karen Broome
>
> -----Original Message-----
> From: Doug Ewell [mailto:doug@ewellic.org]
> Sent: Monday, July 25, 2011 10:43 AM
> To: ltru@ietf.org
> Cc: Broome, Karen
> Subject: Re: [Ltru] Proposed -t0- subtag
>
> "Broome, Karen" <Karen dot Broome at am dot sony dot com> wrote:
>
> > Sorry, I was thinking the original ISO registration had gone through
> > as 'No Linguistic content' but now I'm remembering that this was
> > somewhat of a partner tag for 'zxx' which does mean that. I wasn't
> > referencing the RFC text per se, which gives the user an option — and
> > I'm OK with the option. Still, I generally find this muddy. I don't
> > want to look to a script tag to define the language mode because there
> > are commonly used language modes that are not written forms. The
> > disconnect with the 'zxx' tag this tags mirrors may be another reason
> > to avoid use to indicate the language mode.
>
> I think what you are finding "muddy" is not the subtag 'Zxxx', which
> does have a fairly clear meaning in BCP 47, but rather the use of a
> script (writing system) subtag to tag content that isn't written.  I can
> see how this is unintuitive.  I think the answer is that BCP 47 tags
> aren't really designed to tag modes out of the box, and that, in turn,
> is exactly what extensions are for.
>
> If you or anyone else did want to create an extension RFC for modes
> ('m', perhaps), you'd probably want to start the discussion by
> identifying the initial values (spoken, written, signed, anything else?)
> and setting constraints.  As examples of the latter, you'd want to
> establish whether male vs. female, shouting vs. whispering, friendly vs.
> angry, handwritten vs. printed, etc. are in scope.
>
> --
> Doug Ewell | Thornton, Colorado, USA | RFC 5645, 4645, UTN #14
> www.ewellic.org | www.facebook.com/doug.ewell | @DougEwell 
>
>
>
> _______________________________________________
> Ltru mailing list
> Ltru@ietf.org
> https://www.ietf.org/mailman/listinfo/ltru
>