Subject: [Slim] script subtag as text medium indicator

From: Gunnar Hellström <[email-masked]>
Date: Thu, 24 Sep 2015 00:16:27 +0200

I guess that we have the language tag experts with us in slim,
so I through out a question a bit related to our topics here:

We have said that it is sad that the language tags do not distinguish 
between spoken and written language.  So that if we had a language tag 
on session level, we would not know if it indicated spoken or written 
language use.
Sign languages have separate language names, so they do not suffer from 
this problem.

But, it seems to me that we could use the script subtag as a written 
language indicator.

If we make the application rule that for a certain application, language 
tag without script subtag means spoken language, and language tag with 
script subtag means written language, then within that application 
domain,  for example

fr would mean spoken French
fr-Latn would mean written French

RFC 5646, says about the script subtag in section 2.2.3
"

	There MUST be at most one script subtag in a language tag, and
        the script subtag SHOULD be omitted when it adds no
        distinguishing value to the tag or when the primary or extended
        language subtag's record in the subtag registry includes a
        'Suppress-Script' field listing the applicable script subtag."

Since it adds distinguishing value for distinguishing written from 
spoken, it is a valid use of the subtag.

However, I see in the IANA language subtag registry that many languages 
( including fr ) have Suppress-Script  registered.
So it adds distinguishing value, but has Suppress-Script. Can this be a 
usage case when it can be accepted to use the script subtag to 
distinguish that it is about written language?

/Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Thu, 24 Sep 2015 10:30:19 -0400

What is the use case where it’s important to differentiate?

I’m not very interested in solving a problem where one session has written spanish and spoken French.  I admit that it could happen, but it’s a corner case.

Brian

> On Sep 23, 2015, at 6:16 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> We have said that it is sad that the language tags do not distinguish between spoken and written language.  So that if we had a language tag on session level, we would not know if it indicated spoken or written language use.
> Sign languages have separate language names, so they do not suffer from this problem.
> 
> But, it seems to me that we could use the script subtag as a written language indicator.
> 
> If we make the application rule that for a certain application, language tag without script subtag means spoken language, and language tag with script subtag means written language, then within that application domain,  for example
> 
> Since it adds distinguishing value for distinguishing written from spoken, it is a valid use of the subtag.
> 
> However, I see in the IANA language subtag registry that many languages ( including fr ) have Suppress-Script  registered.
> So it adds distinguishing value, but has Suppress-Script. Can this be a usage case when it can be accepted to use the script subtag to distinguish that it is about written language?
> 
> /Gunnar
> 
> 
> -- 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 24 Sep 2015 15:29:14 +0000

The indication of written versus non-written was discussed when RFC 4646 and its successor 5646 (the current BCP47) were being created. 

The script subtag was introduced for identifying language content for languages that commonly use more than one script (or for minority cases, such as a transcription of a language into a script not normally associated with that language). It is not commonly used for content in languages that are primarily written in a single script as its presence can interfere with matching of language tags. The Suppress-Script field in the registry was created to help users and implementations avoid the use of the script subtag for these languages. Introducing it to indicate written-ness would be artificial and introduce the issues that Suppress-Script was designed to avoid.

The other thing you have to think about is that written content is the norm, not the exception. While there are ample examples of non-written content (movie soundtracks, songs, etc.), presence of language tags in a document is normally closely associated with text.

HTH,

Addison

Addison Phillips
Principal SDE, I18N Architect (Amazon)
Chair (W3C I18N WG), Editor (BCP47)

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: SLIM [mailto:[email-masked]] On Behalf Of Brian Rosen
> Sent: Thursday, September 24, 2015 7:30 AM
> To: Gunnar Hellström
> Cc: [email-masked]
> Subject: Re: [Slim] script subtag as text medium indicator
> 
> I’m not very interested in solving a problem where one session has written
> spanish and spoken French.  I admit that it could happen, but it’s a corner
> case.
> 
> Brian
> 
> > I guess that we have the language tag experts with us in slim, so I
> > through out a question a bit related to our topics here:
> >
> between spoken and written language.  So that if we had a language tag on
> session level, we would not know if it indicated spoken or written language
> use.
> > If we make the application rule that for a certain application,
> > language tag without script subtag means spoken language, and language
> > tag with script subtag means written language, then within that
> > application domain,  for example
> >
> > RFC 5646, says about the script subtag in section 2.2.3 "
> >
> > So it adds distinguishing value, but has Suppress-Script. Can this be a usage
> case when it can be accepted to use the script subtag to distinguish that it is
> about written language?
> >
> > /Gunnar
> >
> >
> > --

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 25 Sep 2015 08:24:35 +0200

In a real-time conversational call, spoken language can be said to be 
the default.

And it is also the only possible if you have only audio enabled. But if 
you have text or video media enabled as well, then you get more choices.

The simple other cases are that you want your real-time calls in written 
language in a two-way text stream, or in sign language in a two-way 
video stream.

Just enabling text or video medium in a call is not at all sufficient 
for indicating what you want to use for language communication.

I was thinking of if we could define how to handle the most simple 
real-time cases with a pre-SLIM method.

We then could use the SIP media tags and language tags, or SDP language 
tags.
SIP media tags are only on session level. SDP media tags can be used 
both on common session level and on media level.

If we use SDP language tags on media level, then we do not need any 
discrimination between spoken and written language tags,
but if we want to use a session level indication, we need to be able to 
specify in what modality the language is.

Therefore a session level indication from a person who need to use 
written English would be en-Latn,
while a person who want to speak English would specify en or nothing.

A call from a person specifying en-Latn to one specifying en or nothing 
could pull in a relay service to support with modality translation 
between text an voice both ways.
A call center with capability to handle both spoken and written modality 
would also get an indication on how to answer a call. If there is an 
en-Latn indication, then it is appropriate to respond with a written 
phrase in English. That avoids initial confusion.

Without the en-Latn indication there would be no base for a decision to 
invoke a relay service or how to answer a call.

But this reasoning has a couple of problems:
1. This would be against the SHOULD NOT for using the script tag 
indicated by the Suppress-Script field ( that is present on many common 
languages).

2. We would also need an application agreement that for this kind of 
application the language tag without script is not used for written 
language.

Are these two obstacles enough for saying that we should not try to 
create this kind of session-level pre-SLIM method?

Gunnar

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Sep 2015 10:17:28 -0400

Inline...

> specify in what modality the language is.

That may a good argument for using media level.

> between text an voice both ways.

For this to work, there must be a text medium between the caller to the 
relay. So then it could specify en on the media level, or en at the 
session level together with text media could imply written english.

> phrase in English. That avoids initial confusion.

Again, can only respond in text if there is a textual medium. And if 
there is, it makes sense to use it.

	Thanks,
	Paul

>> The indication of written versus non-written was discussed when RFC
>> 4646 and its successor 5646 (the current BCP47) were being created.
>>
>> The script subtag was introduced for identifying language content for
>> languages that commonly use more than one script (or for minority
>> cases, such as a transcription of a language into a script not
>> normally associated with that language). It is not commonly used for
>> content in languages that are primarily written in a single script as
>> its presence can interfere with matching of language tags. The
>> Suppress-Script field in the registry was created to help users and
>> implementations avoid the use of the script subtag for these
>> languages. Introducing it to indicate written-ness would be artificial
>> and introduce the issues that Suppress-Script was designed to avoid.
>>
>> The other thing you have to think about is that written content is the
>> norm, not the exception. While there are ample examples of non-written
>> content (movie soundtracks, songs, etc.), presence of language tags in
>> a document is normally closely associated with text.
>>
>> HTH,
>>
>> Addison
>>
>> Addison Phillips

---

From: Brian Rosen <[email-masked]>
Date: Fri, 25 Sep 2015 09:38:25 -0700

> Are these two obstacles enough for saying that we should not try to create this kind of session-level pre-SLIM method?
Yes, I think it is