VoiceOver tweaks need for TTS App which provide unsupported languages.

Warning long, technical post reporting on VoiceOver features slash bugs.

I am posting on behalf of the developers of the TTS App, “RHVoice”.

This TTS is providing voices for a growing number of unsupported languages on Apple operating systems.

The 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.

We wonder if users of any other TTS (e.g. ESpeak-NG) have come across them.

And, perhaps any VoiceOver developers reading this might be interested in improving the situation.

There 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,)

This 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.

But, for unsupported languages, it is as if VoiceOver doesn’t know what to do, and makes some poor decisions, in our opinion.

Example One.  European date format.

  “03.12.2025"

Our Luxembourgish language logic knows this is a date.  

But VoiceOver sends this string to our TTS:

  “03 dot 12 dot 2025”

Where “dot” is the English word - d, o, t - as a string.  Not the symbol, “.”  

This string is now unrecognizable as a date, either to RHVOice or the user listening to the output, where “dot” is a foreign word.

Example 2:    Percent signs

A string like 

    “2%"

is sent to an unsupported languages as

  “2 percent”

The 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.

Example 3. Formatted numbers

   “1.000,30"

This 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.

But, this US/UK formatted version:

  “1,000.30"

A lot of financial and billing systems in Armenia use American software, and so our TTS knows how to handle this number format.  

Given the chance, our users would hear exactly the same spoken number for 1,000.33 and 1.000,33.  

But only if the complete numeric string is given to our TTS.

However, VoiceOver converts the string to “1,000 dot 30”.

That is the word “dot”, not the symbol “.”.  The comma is sent as a symbol.  

It 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. 

In 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.)

Ok, those are three examples.  They present no problem on Android with TalkBack where symbols are left to the TTS to interpret.

There 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. 

If 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.

It would be wonderful if VoiceOver users could benefit soon from RHVoice’s ability to handle numbers properly!

*** If those symbols were simply passed through as characters, without conversion to their English names, that would be wonderful.