[Matroska-devel] Proposal of introducing values to localize the name of a track

Sebastian G. <bastik> bastik.public.mailinglist at gmx.de
Sun Aug 2 15:30:46 CEST 2015


this proposal is preceded by my question [0] on the user-list and the
given response [1].

I'm unaware on how the process of changing the specification works, so I
had considered simply writing an email to the development list, but then
I figured that it might go lost as changes might not happen quick.

Instead I wrote a proposal as a text file that should be attached to
this email. I followed a process I'm vaguely familiar with when it comes
to changing the specification. This process is from the Tor Project,
where bigger changes require a written proposal, which is worked on in
its 'draft' state, then considered 'open', while still be update-able,
then it gets 'accepted' or 'rejected'. Is is 'closed' when it is
implemented or when the proposal is superseded e.g. done, but in a
different way.

The Tor Project publishes and stores proposals in GIT once they reach
the status 'open' and beyond. I'm curious how you handle changing the

The attached proposal basically ask the following:

> Add additional values that take a translation for each 'Name' field
> along with the language that it represents.

Best regards,
Sebastian G. (bastik)

[0] http://lists.matroska.org/pipermail/matroska-users/2015-June/006954.html
[1] http://lists.matroska.org/pipermail/matroska-users/2015-June/006955.html
-------------- next part --------------
Filename: 2015-07-30_trackname_translation.txt
Title: Trackname translation
Author: Sebastian G. (bastik)
Created: 2015-07-30
State: Draft

0. Summary / Background

	This proposal seeks a way to have translations of each trackname to
	satisfy the need of a multilingual target audience.

	A translation approach, with new values, was chosen to maintain
	backward-compatibility, instead of changing the 'Name' values

1. Introduction

	The value 'Name' is supposed to take only strings for one language.
	It is supposed to appear only once or not at all.
	It has no language field attached to it.

	Due to the current specifications of v4 it is not possible to have
	multiple tracknames for people with different languages that don't
	understand each other or can't even read their languages characters.

2. Proposed changes

	Add additional values that take a translation for each 'Name' field
	along with the language that it represents.

	Recommend to fill the 'Name' with the most likely understood string
	considering the target audience. Suggest using the additional fields
	to localize the string to the desired language(s).

2.1. Suggested values

	Add 'NameTranslation' which would not be mandatory, could appear
	multiple times, has no default value and is a UTF-8 encoded string.

	Add 'NameTranslationLanguage', which would not be mandatory, unless
	'NameTranslation' appears. it can occur multiple times, as often as
	'NameTranslation' appears. It doesn't need a default value, because
	applications that wouldn't find the language they are looking for
	wouldn't display any of the translations. It is a sting in form a
	ISO-639-2 encoded language.

	A value to specify the country doesn't seem to be required, since this
	proposal is about ensuring the user understands the displayed string,
	not that it fits his geographical location. Still it shouldn't hurt.

3. Compatibility considerations

	As written above, changing the semantics of 'Name' would result in
	losing backward-compatibility. This seems to be too much for to
	little gain.

	Players encountering 'NameTranslation' and 'NameTranslationLanguage'
	are supposed to ignore them if they don't understand them.

	Players that don't support the new values are expected to use
	'Name' as they have been previously.

	Through settings users can control their player to display strings
	for their language(s) they understand. If a player does not find 
	a string with a matching language it should fall back to 'Name'.

4. Missing

	This proposal does not deal with the level the value would be found
	at, but 'Name' is '3' so it could be '3' as well for the new values.

	It does not deal with the EMBL IDs.

	It does not consider if it requires to change the matroska version.

	It does not deal with implementation, neither writing nor reading.

5. Future

	If you ever have to break backward-compatibility, either before
	or after you changed the specification according to this proposal,
	you could change the semantics of 'Name'.


	ISO-639-2 (https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes)

More information about the Matroska-devel mailing list