Open NhanNguyen700 opened 1 month ago
I've the feeling that adding a Language
attribute to Item would do the trick but I may be missing something 🤔 On reading the ttml, language attribute should of an item would be update accordingly and on writing, we could either repeat the xml language
attribute for each item (which would be simpler in the code), or add separate divs if we detect an item with a language 🤔
All the parsing will return the result as object Subtitles, and there is only one master language for the whole object, we can not know which Items belong to which language, that's why. If we want to fix it, we will break the Subtitles object structures and affect user of this library, they need to change their code to adapt with new structure. There is a way to achieve fixing the issue by storing language for each Subtitles Items, yeah, just like what you said, but it sounds inefficiency. But seems like that it is the only way for this current structure. And then, a question pop up. When converting the multiple languages TTML to WebVTT (or other formats), should we output multiple WebVTT files? I think it is yes, we should append the language into the name of WebVTT file for distinguishing them.
If we want to fix it, we will break the Subtitles object structures and affect user of this library, they need to change their code to adapt with new structure
Which changes are you thinking about? 🤔
Nothing special, just do not store Items
directly in Subtitles
, we can have some kind of Wrapper that store metadata (contains languages) and Items
, then Subtitles
can include that Wrapper. Another way is returning a list of Subtitles objects which different languages when parsing from the input, instead of just returning only one object like what we are doing currently. Those are my thoughts.
Hi,
This is valid in TTML:
After parsing it and write it as TTML again, I expect that we still have two
div
tag with different languages, but I have this:Languages are gone, and texts are merged into one
div
tag.I am looking for a way to fix this, but with the current structure of the lib, It is hard to achieve that without breaking anything.