[voicerss] Add supported voices

[curlyboi]

Added all supported voices for the individual languages taken from API docs. When asked about voices list without locale, it will return all of them, when asked about particular locale, only voices for that locale are returned.

Signed-off-by: cURLy bOi [email protected]

[lolodomo]

Additionnally, is it a change that will break all existing setup ?
For example, my current setup is with that:

org.openhab.voice:defaultVoice=voicerss:frFR

What should be the new value ?
Will it still work with my current value ?

Did you check the result with the existing console command voice voices ?

[curlyboi]

Additionnally, is it a change that will break all existing setup ?
For example, my current setup is with that:

org.openhab.voice:defaultVoice=voicerss:frFR

What should be the new value ?
Will it still work with my current value ?

Did you check the result with the existing console command voice voices ?

i did not because i don't even have java devenv. my commit is simply a suggestion how to implement the full api. i don't think it is possible to endlessly keep backwards compatibility with old systems and this would be a fix that's easily solved anyway.

[lolodomo]

That means you propose a PR you even did not test !!! Very dangerous. The strict minimum would be to mention it.

[curlyboi]

That means you propose a PR you even did not test !!! Very dangerous. The strict minimum would be to mention it.

Fair point, I will remember it. I have 20 years of programming experience and had my Java pro friend code-review it to make sure it's not absolute rubbish :)

[lolodomo]

I suggest to not merge this PR as it was not tested, even not by his author.
I will test it myself but it is not in my priorities.

[lolodomo]

By the way, the PR is not compiling.

[curlyboi]

By the way, the PR is not compiling.

Fixed the typo. Assuming it will compile, can I test this by grabbing an artifact somewhere, putting it in /var/lib/wherever and test myself?

[lolodomo]

My feeling is that you could simply keep backward compatibility by keeping VoiceRSS in all your list of voices.

Regarding locale.toLanguageTag(), I don't know if this clear for you what value it returns but it is not for me.

[lolodomo]

locale.toLanguageTag() returns for example fr-FR so the toLowerCase() was necessary.
By the way, your code is not sufficient as each voice must have a unique ID and this is not the case with your current code.
I will propose my version that will be backward compatible.

[curlyboi]

My feeling is that you could simply keep backward compatibility by keeping VoiceRSS in all your list of voices.

So you propose that each locale's map will contain the individual voices, and then also VoiceRSS which will translate to "nothing" (not calling a specific voice)? This seems like adding unnecessary clutter just because your particular system has it like this.

[curlyboi]

By the way, your code is not sufficient as each voice must have a unique ID and this is not the case with your current code.

Here you are right. Furthermore, I just realized that the voice is not taken into account in the createURL, so even though the voice is selectable, it would make no difference in the actual API call. So thank you for making me realize this.

[lolodomo]

I have done the required changes (backward compatibility + new voice UID) but I always get the same voice. I imagine the voice has to be passed to the request.

[curlyboi]

I imagine the voice has to be passed to the request.

Exactly. The createURL needs to take the voice as another argument, that is passed from getTextToSpeech (so that needs to be added there as well and passed to the createURL) and finally, this is called from VoiceRSSTTSService.java in synthesize, where you have the Voice object with the available voice name.

In the API URL, the parameter is simply v, so &v=Iva for non-default French voice.

[lolodomo]

This was clearly not a change that can be done without compiling and without any testing !!!!
I am on it.

[curlyboi]

This was clearly not a change that can be done without compiling and without any testing !!!!

You are right. Maybe this will finally get me to create a dev environment so I can properly dev plugins.

[lolodomo]

Ok, I have something working.
This was even more complicated as the cache has to be enhaced too.

Considering the number of changes, the best solution would be that I create my own PR. Are you ok ?

[lolodomo]

Regarding the backward compatibility, it consists only in adding a "default" voice with the same UID as before (the UID is what every user has set). And I also take care to reuse the same cached files when this "default" voice is set.
This is clean in my point of view.
I will publish my PR tomorrow.

PS: I switched to Zola voice ;)

[lolodomo]

To be closed (very partial implementation not working).

[curlyboi]

Agreed to migrate to different PR.

[curlyboi]

PS: I switched to Zola voice ;)

I only have this "Josef" dude :D Would prefer a girl too.