Hi!
Although it's not addressed to me, hope I won't intrude if I give some
thoughts.
I guess the answer is yes (and it also works with other defined complex
symbols like in the french version of the file), and as I'm interested as
well by this behaviour because the Romanian language also uses the comma
punctuation for separating decimals, I decided to have some tests.
Adding the point in the "decimal point" rule actually instructs NVDA to
also send each point apart from the commas that are found in a number to
the synth. I tested with a voice for Microsoft SAPI 5 and with one from
eSpeak and the good (at least interesting if not good ) thing about adding
the point is that it allows the synth to correctly interpret the points as
formatting separators for thousands, which they are.
So both eSpeak and SAPI5, in my case, would read 8.000.000,9 as "eight
million point nine" (and not "eight dot zero zero zero dot...."). This
doesn't happen if I don't have the point added to the rule (maybe it also
has to do with the rule for the point symbol which is found below in the
symbols.dic file , but I couldn't tell if changing the level from "most"
will have an impact on this). Now this behaviour could be considered an
improvement in reading, but it wouldn't be such a feature for a person that
wants to use the number and thinks it actually doesn't have formatting. So
don't know what to say about it.
What I found that differs between the two synths is the way the decimal
part is read exactly as in Jamie's example above. The romanian eSpeak
pronounces the decimal part of the number as if it were a composed number
which is incorrect, while the SAPI voice correctly spells each character
after the decimal point. This doesn't have anything to do with the added
dot in the regular expression and is probably language specific, but just
wanted to point it out as it has been mentioned in the discussion.
2016-03-06 17:17 GMT+02:00 ChrisLeo <llajta@xxxxxx>:
Yes Jamie, Thanks for clarifying. I know this.
I Asked the meaning of line 21 to move the question on my preview query
(How it should be read in Slovak?)
and to understand the intention of the slovak translators.
From further investigation I noticed that in Slovak it would be, for
example:
0,6 nula celých šest desatín (Literally is 0 wole six decimal)
1,06 jedna celá šest stotín
2,6 dve celé šest desatín
5,6 pät celých šest desatín.
Fortunately the word "desatín" is often omitted.
Maybe preserve always the decimal poin tfor some synth is great, but not
for eSpeak slovak properties.
I'm not a slovak speaker, I'm just interesting to fix this in eSpeak-NG.
Just one question more:
Is it allowed on NVDA to enter more characters as a set of characters in
symbols.dic?
e.G. to match both point or comma:
decimal point (?<![^\d -])[\.,](?=\d)
-.
Thanks.
Chris.
James Teh, 05/03/2016 12:45:
On 5/03/2016 1:06 AM, ChrisLeo wrote:NVDA translations:
In symbols.dic for SK language on line 21 I read:No. While there is no pronunciation defined, the "always" means that we
"decimal point none always # desatinná čiarka".
this means the decimal point is not pronounced?
pass the raw symbol to the synth in all cases. The reason we do it this
way is that synths know how to process numbers if you provide the raw
symbol. For example, in English, 1.10 must be pronounced "1 point 1 0",
not "1 point 10", which is what you would get if you defined the
pronunciation and didn't let the synth handle it. There are very few
cases where we do this, but decimal point is one of them.
Of course, this relies on the synth correctly supporting the decimal
point for your language. If it doesn't, this obviously isn't going to
work properly.
Jamie
----------------------------------------------------------------
Team documentation: http://community.nvda-project.org/wiki/Translate
To send a message to the list: nvda-translations@xxxxxxxxxxxxx
list archive: //www.freelists.org/archive/nvda-translations/
To change your list settings/unsubscribe:
//www.freelists.org/list/nvda-translations
To contact list moderators: nvda-translations-moderators@xxxxxxxxxxxxx
