Change Details

As was pointed out by @Bawolff in [[https://www.mediawiki.org/wiki/Extension_talk:Wikispeech#Questions_from_wikitech-l | this discussion]], the current implementation (postentially) adds a lot of HTML. At the moment, all cleaned text is added again, under the `utterances`-element. While this may be necessary when a client doesn't use JS, it would be good to avoid when possible. It would also make further development easier, as working with HTML elements as "data containers" can be quite cumbersome. ==Decision== TBD ===Reasoning=== ... ==Options== # **[[https://en.wikipedia.org/wiki/Ajax_%28programming%29 | AJAX]]:** * Pros: * Seems to be designed for things like this. * Cons: * ... # **Streamlining HTML:** If no other solution is found, it should still be possible to decrease the amount of HTML that needs to be added, e.g. by storing string positions, rather than the strings themselves. * Pros: * Most of current implementation of preprocessing can be kept as it is. * Cons: * Still adds HTML.

As was pointed out by @Bawolff in [[https://www.mediawiki.org/wiki/Extension_talk:Wikispeech#Questions_from_wikitech-l | this discussion]], the current implementation (postentially) adds a lot of HTML. At the moment, all cleaned text is added again, under the `utterances`-element. While this may be necessary when a client doesn't use JS, it would be good to avoid when possible. It would also make further development easier, as working with HTML elements as "data containers" can be quite cumbersome. ==Decision== Ajax request to action API ===Reasoning=== * Making API requests to cleaning and segmenting allows easy re-use * Storing the data as a JS-object makes handling easier * Ajax request(s) removes the need to store this in the html * If a user does not use Wikispeech the process will not have to be run. ===Known Trade-offs=== * Likely harder to implement solution for No-JS * No pre-loading of first utterance (at least not as default) ===Follow-up tasks=== * Implement new utterance storage ** Build API module ** Request to API ** Update existing code to use new utterance storage * Implement No-JS workaround ==Options== # **[[https://en.wikipedia.org/wiki/Ajax_%28programming%29 | AJAX]]:** * Pros: * Seems to be designed for things like this. * Cons: * ... # **Streamlining HTML:** If no other solution is found, it should still be possible to decrease the amount of HTML that needs to be added, e.g. by storing string positions, rather than the strings themselves. * Pros: * Most of current implementation of preprocessing can be kept as it is. * Cons: * Still adds HTML.

As was pointed out by @Bawolff in [[https://www.mediawiki.org/wiki/Extension_talk:Wikispeech#Questions_from_wikitech-l | this discussion]], the current implementation (postentially) adds a lot of HTML. At the moment, all cleaned text is added again, under the `utterances`-element. While this may be necessary when a client doesn't use JS, it would be good to avoid when possible. It would also make further development easier, as working with HTML elements as "data containers" can be quite cumbersome. ==Decision== TBDAjax request to action API ===Reasoning=== ...* Making API requests to cleaning and segmenting allows easy re-use * Storing the data as a JS-object makes handling easier * Ajax request(s) removes the need to store this in the html * If a user does not use Wikispeech the process will not have to be run. ===Known Trade-offs=== * Likely harder to implement solution for No-JS * No pre-loading of first utterance (at least not as default) ===Follow-up tasks=== * Implement new utterance storage ** Build API module ** Request to API ** Update existing code to use new utterance storage * Implement No-JS workaround ==Options== # **[[https://en.wikipedia.org/wiki/Ajax_%28programming%29 | AJAX]]:** * Pros: * Seems to be designed for things like this. * Cons: * ... # **Streamlining HTML:** If no other solution is found, it should still be possible to decrease the amount of HTML that needs to be added, e.g. by storing string positions, rather than the strings themselves. * Pros: * Most of current implementation of preprocessing can be kept as it is. * Cons: * Still adds HTML.