2024-07-13, 03:21 PM
Hello everybody,
while curating my audio and subtitle tracks I figured that Jellyfin doesn't properly recognise language codes in the metadata of said tracks.
The following will contain a lot of definitions and nomenclature gibberish. Feel free to have a look on Wikipedia, for example here or here.
Apparently, Jellyfin uses the "IETF BCP 47 language tag", which in turn is based on the ISO 639 norm. The latter defines either two-letter codes (ISO 639-1) or three-letter codes (ISO 639-2 and ISO 639-3) for languages. To make matters worse, ISO 639-2 defines two codes for some (important) languages, a "bibliographic" code (ISO 639-2/B) which is the abbreviation of the language in english and a "terminological" code (ISO 639-2/T), the abbreviation of the language in its native tongue. The latter seems to be preferred and got adopted into the ISO 639-3 standard.
For example, the language codes for German are:
ISO 639-1: de
ISO 639-2/B: ger
ISO 639-2/T: deu
ISO 639-3: deu
Doing some tests, only 'deu' as language tag will lead to correct recognition for the track selection in Jellyfin, yielding a track name like "Surround 5.1 - German - Dolby Digital".
'ger' yields "Surround 5.1 - Ger - Dolby Digital" whereas 'de' yields "Surround 5.1 - De - Dolby Digital", which is basically just the entered language tag capitalised. (pictures are attached)
Though German is chosen as an example, this should apply to other languages as well, in particular those that also have a bibliographic code, for example French.
This inconvenience becomes a problem when using MKVToolNix, which always writes 'ger' because of its (actually powerful) language GUI, in turn breaking correct parsing in Jellyfin.
In my honest opinion, the parser should cover all nomenclatures and hence recognise all of these codes, as it is done elsewhere (for example VLC).
Am I doing something wrong or is that a proper bug?
I found two GitHub issues that are probably related, namely #6302 and #9072, although these go more into details like regional variants and the problem of this thread here is way more fundamental.
Sorry for the long post. Hopefully it helped at least somebody to understand, why their stuff isn't working.
Best regards
while curating my audio and subtitle tracks I figured that Jellyfin doesn't properly recognise language codes in the metadata of said tracks.
The following will contain a lot of definitions and nomenclature gibberish. Feel free to have a look on Wikipedia, for example here or here.
Apparently, Jellyfin uses the "IETF BCP 47 language tag", which in turn is based on the ISO 639 norm. The latter defines either two-letter codes (ISO 639-1) or three-letter codes (ISO 639-2 and ISO 639-3) for languages. To make matters worse, ISO 639-2 defines two codes for some (important) languages, a "bibliographic" code (ISO 639-2/B) which is the abbreviation of the language in english and a "terminological" code (ISO 639-2/T), the abbreviation of the language in its native tongue. The latter seems to be preferred and got adopted into the ISO 639-3 standard.
For example, the language codes for German are:
ISO 639-1: de
ISO 639-2/B: ger
ISO 639-2/T: deu
ISO 639-3: deu
Doing some tests, only 'deu' as language tag will lead to correct recognition for the track selection in Jellyfin, yielding a track name like "Surround 5.1 - German - Dolby Digital".
'ger' yields "Surround 5.1 - Ger - Dolby Digital" whereas 'de' yields "Surround 5.1 - De - Dolby Digital", which is basically just the entered language tag capitalised. (pictures are attached)
Though German is chosen as an example, this should apply to other languages as well, in particular those that also have a bibliographic code, for example French.
This inconvenience becomes a problem when using MKVToolNix, which always writes 'ger' because of its (actually powerful) language GUI, in turn breaking correct parsing in Jellyfin.
In my honest opinion, the parser should cover all nomenclatures and hence recognise all of these codes, as it is done elsewhere (for example VLC).
Am I doing something wrong or is that a proper bug?
I found two GitHub issues that are probably related, namely #6302 and #9072, although these go more into details like regional variants and the problem of this thread here is way more fundamental.
Sorry for the long post. Hopefully it helped at least somebody to understand, why their stuff isn't working.
Best regards