This seems to happen on VAPI side, as I am sending the full words for replacement in templates. Call ID:

48e17c2f-f430-4e6f-a31e-408de31f3aa2

What I sent for replacement in `assistantOverrides.variableValues`: pani Petra Moryš-Beňová What seems to have been provided for the TTS (based on transcript): pani Petra Mory B. Owe Funnily enough, any non-latin characters remain intact when I don't use variableValues, but provide full

firstMessage

content in the API call to VAPI. Call ID:

d1ec5ed0-5e51-44ef-a314-7048b97aa08e

What I sent in `assistantOverrides.firstMessage`: "Dobrý deň pani Petra Moryš-Beňová, volám ..." And it was processed correctly.

@edvordo It seems like there might be an issue with the way the text-to-speech engine is handling the

variableValues

when they are passed separately from the

firstMessage

. It's good to know that when you provide the full content in the

firstMessage

, the non-Latin characters are pronounced correctly. To address the issue with the pronunciation when using

variableValues

, you might need to adjust the configuration of your voice pipeline or look into how the TTS engine is interpreting the variables. It could be a matter of how the TTS engine is parsing the text when it's broken down into variables versus when it's part of a larger, continuous string. If you haven't already, you could try explicitly specifying the pronunciation for the variable values using phonetic or other markup languages supported by the TTS engine. This might help ensure that the names and words are pronounced as intended when they are used as variables. If you need further assistance with this issue or if you'd like to explore more advanced configuration options, please ask support for more info on this.

@Vapi The issue is not with TTS engine, VAPI seems to just strip the non-latin characters when replacing variables with values provided in API call

@edvordo I understand the issue now. It appears that there might be a problem with the way VAPI is handling the

variableValues

when they contain non-Latin characters. This could be due to encoding issues or a bug in the variable replacement logic. To resolve this, I would recommend reaching out to the VAPI support team with the details you've provided here, including the Call IDs and the discrepancies in the TTS output. They should be able to investigate the issue further and provide a solution or a workaround. In the meantime, as a temporary measure, you could continue to use the full

firstMessage

content in the API call to ensure the correct processing of non-Latin characters. If you need assistance in contacting support or if there's anything else I can help you with, please let me know.

@Vapi please assist with contacting support

@edvordo Sweet. Have a great day!

@edvordo can you send a email at support@vapi.ai

Done. Used the same subject as in this forum thread. Thank you!