Using the web server POST API, I found voice key selection a little confusing. I could enter a speakerless key like en_US/vctk_low without escaping the /, which made me think the # in en_US/vctk_low#p238 wouldn't need to be URI encoded as %23 either. I expected the API to parse the fragment and convert it to a speaker. Not so, it simply ignores the fragment, which puzzled me for some time figuring out how to set a speaker.
I would like the API to parse any fragments and append them to the last query with a hash sign. This would make it consistent with not needing to escape the /.
The current workaround is simply to use %23 as an escaped replacement for a hash in POST requests. It makes sense for a web API to require this, but it made my user experience worse due to confusion with the /.
Another aid could be to give an example in the documentation where the curl query has a speaker set, which would include the escaped #.
Using the web server POST API, I found voice key selection a little confusing. I could enter a speakerless key like
en_US/vctk_lowwithout escaping the/, which made me think the#inen_US/vctk_low#p238wouldn't need to be URI encoded as%23either. I expected the API to parse the fragment and convert it to a speaker. Not so, it simply ignores the fragment, which puzzled me for some time figuring out how to set a speaker.I would like the API to parse any fragments and append them to the last query with a hash sign. This would make it consistent with not needing to escape the
/.The current workaround is simply to use
%23as an escaped replacement for a hash in POST requests. It makes sense for a web API to require this, but it made my user experience worse due to confusion with the/. Another aid could be to give an example in the documentation where thecurlquery has a speaker set, which would include the escaped#.