Set Voice To input is droppable but expected inputs don't match expectations

[BryceLTaylor]

Expected Behavior

If you drop a variable reporter into the input for the block "Set Voice To" then if you input the names of the voices as they appear on the blocks, then it should change the voice to that name.

Alternatively accepting non-case sensitive strings of the names would make sense.

Actual Behavior

Since it accepts the EXACT id string used by the vm, which is case sensitive, it accepts the value "GIANT" and "TENOR" but not "giant" and "tenor" despite the fact that the dropdown uses lower case names for the voices.

This came from a forum post: https://scratch.mit.edu/discuss/topic/408699/

Steps to Reproduce

Add the text to speech extension to a project.
Create this stack: Note: the dropdown menu shows all names of the voices in lower case: But only if you put the names in all caps does it accept the inputs.

Operating System and Browser

Mac Chrome (almost certainly others.)

[ericrosenbaum]

Basically, at the time this extension was created, extensions menus did not have the option not to accept dropped inputs ("droppability"). the fact that you can set the voice if you happen to know the exact id string used in the VM is not really a feature, more like an unintended side effect.

If we wanted to turn it into a feature, we would want it to be case-insensitive, but it would also need to work every language. I don't think we have an example yet of using the localized menu item strings as data in the VM. I'd be curious to learn if we can easily do that. I wonder if @chrisgarrity has any ideas!

[ericrosenbaum]

Another idea would be to make the droppability work like it does in the music extension's "set instrument" and "play drum" menus, which include numbers in the menu items (e.g. "(1) piano") which work as dropped inputs. no localization issue. So we could do e.g. "(1) alto, (2) tenor" etc.

[ericrosenbaum]

It's worth noting as well that there are several blocks in the core, and at least a dozen other blocks in the extensions, that have this issue (i.e. droppable menus where if you know the VM id string in English, you can set it using a variable, but otherwise droppability does not work). it seems more relevant in some cases than others- this specific one of setting the voice with a variable would be particular nice to have.

[ericrosenbaum]

So we can indeed access the translated voice names for the current locale, like this: Object.keys(this.VOICE_INFO).map(v => this.VOICE_INFO[v].name)

Which e.g. for spanish returns ["contralto", "tenor", "chillido", "gigante", "gatito"]

We could check against that list to set the voice using a dropped string. There's still a potential problem here though: supposing we did that, and people used it. They would be making projects that work only in their own language. If somebody makes a project with a voice set using a variable to gigante, and I view it with the site set to English, it won't work. So we would need to do something like what we did for the language names here as well, which is to collect the translations into every language, and check against all of them. Not sure if that's possible with our setup.