feat(languages): expand language config to accept arrays

[KimKyuHoi]

Previously, the player only accepted a single preferred language for audio and text tracks. This was limiting because browsers provide a list of preferred languages through navigator.languages, not just one.

For example, when a user has their browser set to ['ko-KR', 'ko', 'en-US', 'en'], the player could only use the first one ('ko-KR'). If the content didn't have Korean audio or subtitles, the player had no way to know that English would be an acceptable fallback.

Now the player accepts an array of languages and checks them in order:

  User browser: ['ko-KR', 'ko', 'en-US', 'en']
                       ↓
  Video loads → Check ko-KR? No → Check ko? No → Check en-US? No → Check en? Yes!
                       ↓
                English audio selected

The config fields are renamed to reflect this change:

• preferredAudioLanguage → preferredAudioLanguages
• preferredTextLanguage → preferredTextLanguages

The demo app now uses navigator.languages directly, so users get sensible defaults based on their browser settings without any manual configuration.

BREAKING CHANGE: preferredAudioLanguage (string) → preferredAudioLanguages (string[])
BREAKING CHANGE: preferredTextLanguage (string) → preferredTextLanguages (string[])

[avelad]

Related to #1591

[shaka-bot]

Incremental code coverage: 69.70%

[tykus160]

FYI there was a discussion in topic linked and instead of your proposal, we were thinking about more configurable objects, see #1591 (comment), #1591 (comment) & #1591 (comment)

[matvp91]

I appreciate the effort, but I'm not confident this would hold up over time. I would strongly prefer reducing the set of streams using a list of preferences (see the linked comments from @tykus160).

Allowing multiple languages introduces questions around multiple roles, codecs, and their possible combinations. The recent text track simplification likely makes integration more straightforward. We should be careful introducing this as a proper v5 API as we'll have to maintain backwards compatibility for a while.

@KimKyuHoi, would you be willing to experiment with the proposed idea's in #1591 as opposed to solely allowing multiple languages?

[KimKyuHoi]

@matvp91 Ah, I totally misunderstood (@avelad comment)! I thought that meant I had to maintain backwards compatibility. Thanks for clarifying that it's a breaking change release. That definitely makes the implementation simpler/cleaner. I will proceed without supporting the legacy config.

[matvp91]

Yes, we can break backwards compatibility with the introduction of a next major version.

I'm sorry I'm expanding scope so much for a change that should be relatively straight forward, but I feel we shall take advantage of the fact that we're going to bump a major version in order to get track preferences right from the get go. Nonetheless, we're here to help.

@tykus160, do you think implementing this in shaka.media.PreferenceBasedCriteria is a good strategy?

I'd love to hear everyone else's opinion though!

[KimKyuHoi]

@matvp91 I think it's a good suggestion. Then, why don't we open a new issue, create a relation, and proceed further? I'm making this suggestion because I'm going to be taking charge of it anyway. I was concerned that if we proceeded with the existing PR, the resulting diff files would be too large.

[matvp91]

@KimKyuHoi what works best for you, I'm OK either way.