bug in NVDA, when announcing a Hungarian float number

[nvaccessAuto]

Reported by oaron on 2010-03-10 19:20
In the hungarian espeak version if there is a zero after the decimal sign, nvda reads it incorrectly. This bug occurs because in hungarian the decimal sign is a comma, instead of a dot.

[nvaccessAuto]

Comment 1 by jteh on 2010-03-10 23:42
Changes:
Milestone changed from 2010.1 to 2010.2

[nvaccessAuto]

Comment 2 by jteh on 2010-05-18 05:57
Please be more specific about how it is incorrectly read. That is, provide an example (roughly translated) of a number, what is currently said and what you expect should be said instead.

[nvaccessAuto]

Comment 3 by oaron (in reply to comment 2) on 2010-05-28 19:23
Replying to jteh:

Please be more specific about how it is incorrectly read. That is, provide an example (roughly translated) of a number, what is currently said and what you expect should be said instead.

NVDA announce 0, and after other numbers. E.G 1,023. But, if after the comma the first number doesn't 0, It works well. I tried it with other screen reader (with Espeak) and the numbers announce correctly, because in Espeak there is a Hungarian decimal rule.

[nvaccessAuto]

Comment 4 by jonsd on 2010-05-28 19:49
espeak -vhu "1,023"
correctly says the equivalent of "One point twenty-three thousandths".

Different languages have different rules for speaking decimal fractions.

Generally, if NVDA passes the complete number (including the decimal separator) to the synthesizer, it will be spoken correctly for the language. NVDA needs to recognise that Hungarian uses a comma as decimal separator.

[nvaccessAuto]

Comment 5 by jteh on 2010-05-28 20:10
The reason for this is that NVDA has a rule which separates preceding 0s from other numbers. We do this because some synths strip preceding 0s. eSpeak doesn't seem to be broken in this way, so perhaps this default rule should be removed.

[nvaccessAuto]

Comment 7 by jteh on 2010-07-14 23:06
Fixed in dcce579.
Changes:
State: closed