Cainntear wrote:ryanheise wrote:On an unrelated note, the file format will be similar to what Cainntear proposed, but with room for multiple translations and transcripts.
Code: Select all
"translationLanguages": ["en"], // ISO 639-*
Personally I'd favour using a dictionary for the translations rather than parallel arrays. That would save having a whole load of null values floating around while a translation is work in progress. It also avoids having to add in all the nulls as soon as a new translation is started, if the format is used as a live datatype rather than just the archival format. (For example, if someone built a Vue app to work off the same data or to browse it online, JSON would obviously be the native format.)
That said, you might have solid architectural reasons for your choice.
I'm not tied to that decision apart from the fact that I want the transcripts to be ordered with the primary transcript appearing first (e.g. in dropdown menus). The translations don't particularly need to be ordered (Well, Netflix happens to order available subtitles and audio tracks, but there's not really any inherent or universal order here so translations could be a dictionary with the display order being decided in some other way).
start/end/transcripts/translations can be omitted from parent segments and they will be automatically inferred from the child segments.
"Can be" as in "optional", or "can be" as in "will be...?"
What I'm referring to here is that if the node "AB" lacks a transcript but its children "A" and "B" both have transcripts, then the transcript of "AB" can be inferred by concatenating "A" + "B". Who does the inferring? It is up to whichever program opens the file whether it wants to do that. The same applies to translations. In some cases, it may be useful to insert a special translation for "AB" which is different from the simple concatenation of "A" and "B", particularly if the translation language is very different from the source language with a different word order. The natural translation of "AB" may involve placing words at different ends of the sentence that could not be reconstructed through simple concatenation. The start/end times can easily be inferred. The start time of "AB" comes from the start time of "A" and the end time of "AB" comes from the end time of "B", and this is advantageous since if you edit the timestamps of "A" or "B" they will automatically propagate up the tree.
I'm thinking about materials specifically designed for learners with a pause for response. In certain use cases, the gaps may be considered part of the data, whereas in others they might not, and in certain situations that will correspond to the levels of grouping. Or maybe that can be obviated by automatic silence insertion in your app.
The plan is that there will be gaps, but they will be part of the training routine (which is a separate data structure) rather than baked into the content. The training routine will allow you to vary the gaps depending on the maturity of the segment, for example.