{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreidujkcp4tuwcsoc5zyfnkdrozxpzwddczmz7ftpbnppnwcv23so6y",
    "uri": "at://did:plc:mz7h4r2iyp2egghuqaolnsev/app.bsky.feed.post/3mj65vhq6fjj2"
  },
  "path": "/forum/app-development-programming/voiceover-tweaks-need-tts-app-which-provide-unsupported-languages",
  "publishedAt": "2026-04-10T16:18:24.000Z",
  "site": "https://applevis.com",
  "textContent": "Warning long, technical post reporting on VoiceOver features slash bugs.\n\nI am posting on behalf of the developers of the TTS App, “RHVoice”.\n\nThis TTS is providing voices for a growing number of unsupported languages on Apple operating systems.\n\nThe Android version of the App has, for a long time, provided many such unsupported languages, In moving them to Apple, a few features/bugs in VoiceOver are being encountered.\n\nWe wonder if users of any other TTS (e.g. ESpeak-NG) have come across them.\n\nAnd, perhaps any VoiceOver developers reading this might be interested in improving the situation.\n\nThere are lots of individual facts, but essentially the problem is that VoiceOver seems to make the decision on how to provide certain symbols to a TTS. (And not just in “spell” mode as can be the case with JAWS and NVDA,)\n\nThis symbol interpretation by VoiceOver works fine for supported languages, because VoiceOver knows how those languages (well at least Apple’s TTS) can handle various alpha-numeric strings.\n\nBut, for unsupported languages, it is as if VoiceOver doesn’t know what to do, and makes some poor decisions, in our opinion.\n\nExample One. European date format.\n\n“03.12.2025\"\n\nOur Luxembourgish language logic knows this is a date.\n\nBut VoiceOver sends this string to our TTS:\n\n“03 dot 12 dot 2025”\n\nWhere “dot” is the English word - d, o, t - as a string. Not the symbol, “.”\n\nThis string is now unrecognizable as a date, either to RHVOice or the user listening to the output, where “dot” is a foreign word.\n\nExample 2: Percent signs\n\nA string like\n\n“2%\"\n\nis sent to an unsupported languages as\n\n“2 percent”\n\nThe English word “percent” is thus spoken by the voices, not the local word for “percent\" which would be spoken if the actual symbol (character code) for “%” had been sent.\n\nExample 3. Formatted numbers\n\n“1.000,30\"\n\nThis is the Continental European number representing the English language number “one thousand point (i.e. decimal) three zero”. VoiceOver sends this string to the unsupported language exactly as it is written and the voices speak this number properly in the requested language. Nice.\n\nBut, this US/UK formatted version:\n\n“1,000.30\"\n\nA lot of financial and billing systems in Armenia use American software, and so our TTS knows how to handle this number format.\n\nGiven the chance, our users would hear exactly the same spoken number for 1,000.33 and 1.000,33.\n\nBut only if the complete numeric string is given to our TTS.\n\nHowever, VoiceOver converts the string to “1,000 dot 30”.\n\nThat is the word “dot”, not the symbol “.”. The comma is sent as a symbol.\n\nIt looks like VoiceOver has decided there are two separate number strings, separated by a dot. The first is a European decimal, with three zero decimal places.\n\nIn this case where the word “dot” is inserted, our TTS can only say (The Armenian equivalent of) “one decimal zero zero zero dot thirty”. (The dot is spoken as the English word, whereas the numbers are spoken as Armenian.)\n\nOk, those are three examples. They present no problem on Android with TalkBack where symbols are left to the TTS to interpret.\n\nThere are other examples which would, admittedly not be possible to fix without VoiceOver knowing some unsupported vocabulary. One of those other examples is the English word “Cap” being inserted on the keystroke reporting.\n\nIf any eSpeak app developer is reading this: Do you know about these issues? I think you may be able to create a work-around. But for RHVoice, it would require some major surgery to its core architecture.\n\nIt would be wonderful if VoiceOver users could benefit soon from RHVoice’s ability to handle numbers properly!\n\n*** If those symbols were simply passed through as characters, without conversion to their English names, that would be wonderful.",
  "title": "VoiceOver tweaks need for TTS App which provide unsupported languages."
}