Added support for reading the article aloud using the text to speech API

[kasemmarifet]

Fixes #166: Added support for reading the article aloud using the text to speech API. Added a new button to start reading the opened article. When the speech has started, show a button to stop the speech.

Note that this requires a text to speech API. If browser does not support this API, the read button is not displayed.

[mossroy]

Thanks a lot for that PR, that's cool!

But I have a strange behavior : the drop-down list of voices is most of the time empty on the browsers I tested. Sometimes, after a reload of the page, the drop-down list gets populated, but not always.
I had this behavior on Firefox 61 and Chromium 66 (both on Ubuntu 16.04), and on Firefox 60.1ESR and Chrome 67 (both on Windows 8).
I suspect it's a bug (like a race condition), as I do not have this issue with https://codepen.io/matt-west/pen/wGzuJ for example.

Also, on Ubuntu 18.04 + Firefox 61, I only can use a "default(en)" voice in kiwix-js, where I can use many more in https://codepen.io/matt-west/pen/wGzuJ (and they all seem to work offline)

In the settings section, we have an API status zone, where it would be relevant to put the 2 APIs availabilities (SpeechSynthesisUtterance and window.speechSynthesis, if they are both needed) : it would help diagnosis when it does not work.
It would also be helpful to explain somewhere that the package "speech-dispatcher" is necessary (at least on debian-based linux distributions, see https://bugzilla.mozilla.org/show_bug.cgi?id=1003464) to make it work : this package is not installed by default on lubuntu for example. In this case, even if the API seems to be available in javascript, you get no voices in the drop-down list.

NB : the Travis Continuous Integration fails on this PR because this is a remote branch, not because of your code. We should not worry about that. See travis-ci/travis-ci#9350

[mossroy]

I've tested that feature on Firefox OS 2.5 devices : the API is implemented, and the platform provides a few voices in several languages. I managed to make it read the main page of latest english wikivoyage (on the 1GB RAM device). It's unstable, though, and I suspect it is a platform issue (it's no use investigating on this). I could not make it work on the 512MB device.
In any case, it's cool to hear my phone read wikipedia :-)

[mossroy]

Another small issue in this PR is that it only works in jQuery mode, because the call to showTextToSpeech(); is in function displayArticleContentInIframe. Moving or adding the call in function readArticle should make it compatible with ServiceWorker mode.

[mossroy]

To sum-up the previous comments, there are at least a few things that need to be fixed before this PR could be merged :

• solve the issue of not having any voice in the drop-down list (that is sometimes solved by a reload)
• make that compatible with ServiceWorker mode
• probably some UI enhancement : display the API status, and avoid that long voice strings break the layout (like in the following snapshot)
  @Jaifroid listed many other improvements that would be welcome. But if he's willing to work on the most important ones, merging this PR could be a starting point.

[mossroy]

Here is a snapshot of a broken layout (on Firefox 60.1.0esr / Windows 8.1) with the voices detected on this system

[Jaifroid]

I experience the layout issue also on Edge. I feel we could put the voice selection in the Configuration, especially if we couple it with automatic selection based on the ZIM language. Personally, I feel we could add automatic voice selection to this PR, as it doesn't seem complicated, which would remove the need for explicit voice selection except where the user wishes to override.

Regarding the issues in my todo list in #166 , I'm happy to work on some or potentially all (eventually).

If either @kasemmarifet or @kelson42 could let us know whether we should expect any more external work on this PR or not, we can move forward.

[mossroy]

I think it's time to close this PR, because the requested changes have not been made in the last 3 months.
Anyway, this enhancement would still be worth it IMHO.
And the code already done by @kasemmarifet could be the base for another PR, if someone is willing to carry on his work.
The branch should not be deleted, for that reason.