Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Consider normalizing all language codes to use a single standard #2867

Closed
PiotrWozniakSC opened this issue May 26, 2017 · 3 comments
Closed

Consider normalizing all language codes to use a single standard #2867

PiotrWozniakSC opened this issue May 26, 2017 · 3 comments
Assignees
@tonihei
Labels
enhancement

Comments

@PiotrWozniakSC
Copy link

Version of ExoPlayer used: 2.3.1 (with plans to use latest)

ExoPlayer uses three-letter codes in Format.language for audio and subtitle tracks. Question is - what standard is used for these codes? Is it 639‑2/T, 639‑2/B, 639‑3 (https://en.wikipedia.org/wiki/List_of_ISO_639-1_codes#Partial_ISO_639_table) or some other standard?

The Format.language field description states only "The language, or null if unknown or not applicable." (in v1 it was stated explicitly: "The language codes are two-letter lowercase ISO language codes (such as "en") as defined by ISO 639-1.") and I couldn't find the answer regarding v2 anywhere. I'd be grateful for the clarification.
@ojw28
Copy link
Contributor

ojw28 commented May 26, 2017

Pretty sure we just mirror whatever's in the source media. Assuming the source media uses some vaguely sane standard, then you should be able to normalize it into RFC 5646 using Util.normalizeLanguageCode.

@ojw28 ojw28 added the question label May 26, 2017
@ojw28
Copy link
Contributor

ojw28 commented May 26, 2017

Hm, actually, I'm not about the second part of my answer.

@ojw28 ojw28 changed the title What standard does ExoPlayer use for language code of a track in Format.language field? Consider normalizing all language codes to use a single format Sep 20, 2017
@ojw28 ojw28 changed the title Consider normalizing all language codes to use a single format Consider normalizing all language codes to use a single standard Sep 20, 2017
ojw28 pushed a commit that referenced this issue Nov 27, 2017
@AquilesCanta @ojw28
Support undefined text track language when preferred is not available
16c43c6 
Also slightly improve language normalization/documentation.

For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.

Issue:#2867
Issue:#2980

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
ojw28 pushed a commit that referenced this issue Dec 12, 2017
@AquilesCanta @ojw28
Support undefined text track language when preferred is not available
c1c892f 
Also slightly improve language normalization/documentation.

For this CL, it is assumed that null and "und" languages are different
entities. Once we fully tackle language tag normalization, we can decide
whether to normalize the "undefined" language.

Issue:#2867
Issue:#2980

-------------
Created by MOE: https://github.com/google/moe
MOE_MIGRATED_REVID=177008509
@tonihei tonihei assigned tonihei and unassigned ojw28 Jan 24, 2019
ojw28 pushed a commit that referenced this issue Jan 29, 2019
@tonihei @ojw28
Ensure normalized language code is used everywhere and update documen…
ef8335f 
…tation.

Issue:#2867
PiperOrigin-RevId: 231385677
@ojw28
Copy link
Contributor

ojw28 commented Jan 30, 2019

Fixed in dev-v2.

@ojw28 ojw28 closed this as completed Jan 30, 2019
@google google locked and limited conversation to collaborators Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@tonihei tonihei

Labels
enhancement
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ojw28 @tonihei @PiotrWozniakSC