Subject: Re: [Cellar] using ISO 639-3 language codes in Matroska

From: Reto Kromer <[email-masked]>
Date: Wed, 13 Jan 2016 11:10:07 +0100

Jerome Martinez wrote:

>I don't understand: RFC 4646 is obsoleted by RFC 5646.

Sorry, you are completely correct, my fault! (And I must to
update our own programmes). Best regards, Reto

AV Preservation by reto.ch
chemin du Suchet 5 | 1024 Ecublens | Switzerland
Web: http://reto.ch | Twitter: @retoch

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 14 Jan 2016 10:47:18 +0100

IMO the current tag should remain unchanged. We cannot change the
interpretation now, especially if some values are incompatible.

So at least there should be a new tag. I think it should be a new
Language tag with a more universal scope. Although the RFC spec seem
to cover that, the broad interpretation for each tag may be a problem.
That makes parsing the language a lot more complex (is it 2 or chars ?
with country/regional extensions ?). Is it widely supported already ?

Since there would be 2 tags for the same thing, we should define which
one has priority, if they are exclusive. IMO having an element to
define how another element is to be interpreted should be avoided.
Also it limits the language element to one item. If we have 2 (old and
new) old parsers can still work fine. And newer parsers can pick the
new element prioritarily.

2016-01-13 11:10 GMT+01:00 Reto Kromer <[email-masked]>:
> _______________________________________________
> Cellar mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cellar

-- 
Steve Lhomme
Matroska association Chairman

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 14 Jan 2016 10:59:19 +0100

> interpretation now, especially if some values are incompatible.

+1

> with country/regional extensions ?). Is it widely supported already ?

If we don't start the pump, we will not have something.
We can start with wide definition and implement only what we need for 
both writing and reading, and we see when someone need of the more 
complex part of the RFC.
Anyway, this is not a too big problem, unknown language is displayed by 
the player with the string in the file, understandable.

> one has priority, if they are exclusive.

Not exclusive.
Current tag set as deprecated (for compatibility)
New tag set as the reference (has priority other the old one).

>   IMO having an element to

+1

> new element prioritarily.

+1

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 14 Jan 2016 11:21:09 +0100

> If we don't start the pump, we will not have something.

It seems that it's also endorsed by the W3C:
https://www.w3.org/International/articles/language-tags/

> We can start with wide definition and implement only what we need for both
> writing and reading, and we see when someone need of the more complex part
> of the RFC.

As Dave said, it's better if we leave the definition of such things to
another authority and just be compliant.

> Anyway, this is not a too big problem, unknown language is displayed by the
> player with the string in the file, understandable.

It seems that it's actually not too hard to parse, depending on what
you want. A player/parser/muxer that wants to support language
handling but not too heavily can just stick to the frst 2 or 3 chars
that are common ISO codes. Compared to current parsers it's just
adding mapping for ISO 639-2 codes in additions to ISO 639-3. It's not
that bad.

So I'd vote for a new element that defines the language in the RFC
5646 format and has priority over the old element.

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 14 Jan 2016 11:28:19 +0100

> https://www.w3.org/International/articles/language-tags/

Just to be clear: this is one of the reason I recommend RFC 5646 (beside 
the fact we are now on an IETF list)

> another authority and just be compliant.

Just to be clear: this is the reason I recommend RFC 5646 (it is not  
done by us).
I think that ISO 639-3 alone is not enough and that another group has 
already expanded it for when it is necessary (RFC 5646 recommends to use 
ISO 639 when it is possible)

> adding mapping for ISO 639-2 codes in additions to ISO 639-3. It's not

Not that bad too (because such list is very classic), but you also need 
ISO 639-1 if you don't forbid 2-letter codes (RFC 5646 recommends 
2-letter codes when 3-letters codes are not necessary, if I understand 
well).

> 5646 format and has priority over the old element.

Just to be clear: same as me.

Jérôme

---

From: Steve Lhomme <[email-masked]>
Date: Thu, 14 Jan 2016 11:41:28 +0100

2016-01-14 11:28 GMT+01:00 Jerome Martinez <[email-masked]>:
> Just to be clear: this is one of the reason I recommend RFC 5646 (beside the
> fact we are now on an IETF list)
>
>>
>>> both
> Just to be clear: this is the reason I recommend RFC 5646 (it is not  done
> by us).
> already expanded it for when it is necessary (RFC 5646 recommends to use ISO
> 639 when it is possible)
>
>
>>
>>> the
> Not that bad too (because such list is very classic), but you also need ISO
> 639-1 if you don't forbid 2-letter codes (RFC 5646 recommends 2-letter codes
> when 3-letters codes are not necessary, if I understand well).

Yes, that's what I meant.