Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson comments")

From: "Doug Ewell" <[email-masked]>
Date: Tue, 03 Nov 2015 12:55:49 -0700

Gunnar Hellström wrote:

> How would the difference between spoken and written best be expressed
> in an extended BCP47?

Without expressing any opinion about the use case itself with regard to
SLIM, I'll point out that there are basically three possible ways to do
this conformantly:

1. Private-use subtags (e.g. en-x-spoken, en-x-written)

While this solution would work immediately, out of the box, with no need
to register or publish anything, I realize that just about nobody wants
this solution, and to some extent why.

2. Variant subtags (e.g. en-spoken, en-written)

These would need to be individually registered as per RFC 5646, Section
3.5, via the ietf-languages list. I can say with reasonable certainty
that there would be fairly strong opposition to this approach, as
modality is not generally considered to "define a language or its
dialects" (Section 2.2.5) except in special cases like sign languages.
One might reasonably ask if whispered, shouted, muttered, sung,
displayed on a billboard, skywritten, etc. would also qualify.

3. Registered extension (e.g. en-m-spoken, en-m-written)

This would involve writing and publishing an RFC to define an extension
for "modality" together with an initial list of values, as per Section
3.7. Extensions have been created so far to denote attributes that are
more closely associated with locales than with languages per se, so
there might be some support for this approach. It would, however,
involve the usual lengthy RFC gestation period.

An alternative approach, which I believe has been discussed here before,
would be to encode modality in its own separate attribute, rather than
trying to fit language identification and modality into the same tag.

Hope this helps,

--
Doug Ewell | http://ewellic.org | Thornton, CO 🇺🇸

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 3 Nov 2015 21:31:14 +0100

> trying to fit language identification and modality into the same tag.
That is close to what we have now in the real-time spec, by tacking on 
the language tag to the media specification in SDP.
But it has some drawbacks, in that media types are not strict on what 
modalities they carry, with all these application and message etc media 
types not revealing clearly what they contain.
And I think, the same with Content-Type on the mail side.

So, for the humintlang attribute one solution would be to have a 
parameter for modality.

But it is a general problem that should best be solved at its source - 
in BCP-47. Spoken and written languages are not identical, we just 
believe so at first thought.
This problem makes language tags ambigous in many applications. Users 
usually want to know if they are supposed to read or listen.

Gunnar

---

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 3 Nov 2015 21:04:48 +0000

That's true: spoken and written language are different. As a result, occasionally some spoken or written content needs to use a different language tag from the other modality *because* the value being identified is itself different. This is common, for example, for the Chinese macrolanguage, where the written form generally but not always is some form of Mandarin Chinese in either the Simplified or Traditional script but where the spoken form does not want a script subtag and may need to use the specific subtag for the spoken variety---such as 'yue'.

However, there aren't many cases where the spoken variant and the written variant of a language share a single resource. That is, you don't have any audio recordings containing the written variation of German. The subtitles in a movie are written, but the audio tracks are audio recordings: these may be identified separately. Sign language interpretation of a speech is actually *in* another language in most cases. And so on.

As such, I guess I don't believe that there is much need to introduce a script subtag merely to say that some set of strings (or collection of pixels) is written. That much is usually obvious from the resource itself. Introducing a subtag artificially to convey this information interferes with tag matching and selection (particularly when the selection is automated from existing content). And when the "difference" being identified is already "obvious" to processing, it's not worth the problems it causes. Use language tags to identify language variation and not as a proxy for Content-Type ;-).

> usually want to know if they are supposed to read or listen.

When content is interchanged, users already know whether the exchanged content can be read or can be listened to. It's a property of the data format. If a data format is completely ambiguous, then the receiver won't be able to "play" it?

Addison

> -----Original Message-----
> From: SLIM [mailto:[email-masked]] On Behalf Of Gunnar Hellström
> Sent: Tuesday, November 03, 2015 12:31 PM
> To: [email-masked]
> Subject: Re: [Slim] Primary language tags (was "Re: draft-tomkinson
> comments")
> 
> > An alternative approach, which I believe has been discussed here
> > before, would be to encode modality in its own separate attribute,
> > rather than trying to fit language identification and modality into the same
> tag.
> That is close to what we have now in the real-time spec, by tacking on the
> language tag to the media specification in SDP.
> modalities they carry, with all these application and message etc media types
> not revealing clearly what they contain.
> So, for the humintlang attribute one solution would be to have a parameter
> for modality.
> 
> But it is a general problem that should best be solved at its source - in BCP-47.
> Spoken and written languages are not identical, we just believe so at first
> thought.
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Nov 2015 09:24:22 +0900

Hello Addison,

> As such, I guess I don't believe that there is much need to introduce a script subtag merely to say that some set of strings (or collection of pixels) is written. That much is usually obvious from…

I agree with you with respect to tagging content. But language tags are 
also about requesting content, and there it can make a huge difference 
whether something is spoken or written.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Nov 2015 09:29:17 +0900

> involve the usual lengthy RFC gestation period.

Please note that the SLIM WG is already working on one or more RFCs, and 
that such an extension could be added as part of an RFC, there would not 
be a need to have it as a separate RFC. Also please note that while the 
gestation periods for the RFCs in the LTRU WG have been quite lengthy 
(several years), that's not necessarily the case in every WG.

So I personally could very well see a registered extension for this use 
case.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 9 Nov 2015 09:32:42 +0900

Sorry forgot one important additional thing:

On 2015/11/09 09:24, Martin J. Dürst wrote:
>> As such, I guess I don't believe that there is much need to introduce
>> a script subtag merely to say that some set of strings (or collection
>> of pixels) is written. That much is usually obvious from the resource
>> itself. Introducing a subtag artificially to convey this information
>> interferes with tag matching and selection (particularly when the
>> selection is automated from existing content). And when the
>> "difference" being identified is already "obvious" to processing, it's
>> not worth the problems it causes. Use language tags to identify
>> language variation and not as a proxy for Content-Type ;-).
>

There's also the case of subtitled video. It's spoken in one language, 
and written in another. There are hacks to indicate this with the 
language tags that we have now (using a script subtag on the written 
one, and no script tag on the spoken one), but it's quite a stretch.

Regards,   Martin.

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 9 Nov 2015 07:49:47 +0100

> one, and no script tag on the spoken one), but it's quite a stretch.
[GH] And that stretch was what I proposed to use now again for 
distinguishing spoken from written.
The lack of a differentiation between these have kept me from 
considering language tags for relay service selection and invocation 
many years now. Now that we see that there are other applications having 
the same problem, let us do something about it.

I can see behind the arguments from the language tagging experts that 
there has been problems to find what you want among already set tags, so 
you want to keep the use of extensions low. But I cannot see that the 
difference between spoken and written is a minor detail that should be 
ignored. I think it is more discriminating for the possibility to use 
the content than dialect and script.

Are these motivations convincing enough to start work for a modality 
extension to language tags?

Regards
Gunnar

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