Is the LanguageMatcher supposed to be used on text tracks?

[riksagar]

I notice with DASH-JS v5 that there's a language matcher than normalizes lang=... attributes.

In our UI we try to differentiate things like pt-br and pt-pt so we can preserve the users preference/selection.

While trying to migrate to v5 recently, I found that en-us was getting converted to en and pt-br became pt. However, es-mx got converted to es-MX.

I'm a bit confused. Why did "mx" get capitaized, while "us" and "br" got dropped completely?

Is there a move here to normalize to two character codes?

The PR here - #4036 - suggests the goal is to replace three character codes.

Ironically, ExoPlayer has a library that converts everything to 3 character codes 😕 (or at least it did last time I checked).

Regards,
Rik.

[dsilhavy]

@riksagar I think @stschr can provide more details here, but we stick to what the 6th edition of the DASH specification says on the @lang attribute:

Declares the language code for this Adaptation Set. The syntax and semantics according to IETF BCP47 used.

Per IETF BCP 47, 2-character codes are to be used whenever possible, i. e. 3-character codes are not to be used when there is an equivalent 2-character code.

Other subtags except the primary language subtag, e.g. region subtags such as used in “es-US”, should not be used unless essential in language disambiguation across an Adaptation Set

[stschr]

Hi @riksagar ,
indeed a good question.

For normalizing variations of language tags, we rely on an external library: https://www.npmjs.com/package/bcp-47-normalize
This tool is based on Unicode Common Locale Data Repository (CLDR), which we expect to provide a comprehensive and well-maintained list of overlong or deprecated language codes.

For robust operation we normalize both, user-provided and signaling in the MPD prior comparison.

Does this normalization cause any problems for you?