Proposal of introducing values to localize the name of a track
"Sebastian G. <bastik>" <[email protected]>
| Newsgroups | gmane.comp.multimedia.matroska.devel |
|---|---|
| Message-ID | <[email protected]> |
Hello, 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 specification. 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 _______________________________________________ Matroska-devel mailing list [email protected] http://lists.matroska.org/cgi-bin/mailman/listinfo/matroska-devel Read Matroska-Devel on GMane: http://dir.gmane.org/gmane.comp.multimedia.matroska.devel
2015-07-30_trackname_translation.txt
(text/plain, 3.1 KB)
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 semantics. 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'. Appendix ISO-639-2 (https://en.wikipedia.org/wiki/List_of_ISO_639-2_codes)