The letter and punctuation names remain in the NVDA language even when the synthetizer is configured differently #4210

Closed
nvaccessAuto opened this Issue Jun 20, 2014 · 20 comments

4 participants

@nvaccessAuto

Reported by kredh on 2014-06-20 09:58
The letter and punctuation names (spoken by NVDA synthetizer) are not in the synthetizer language, but remain in the NVDA language. My NVDA language is French, for instance, but when I activate a profile that uses a different synthetizer in English, the letter and punctuation names remain in French (. will be prununced point, not period or dot, for instance).
Blocking #3545

@nvaccessAuto

Comment 1 by jteh on 2014-06-20 10:04
This should already work as you expect if the synthesiser correctly exposes the language and you have automatic language switching enabled. Can you confirm at least the second point?

@nvaccessAuto

Comment 2 by kredh on 2014-06-20 10:11
No, automatic language switching is off (I prefer to do it myself, when given a chance, partly since I don't use the same synthetizer for both languages).

@nvaccessAuto

Comment 3 by jteh on 2014-06-20 11:05
If you disable automatic language switching, NVDA trusts only its own user interface language, not the synthesiser or the document. If you want the symbol language to work as you expect, you need this setting enabled.

@nvaccessAuto

Comment 4 by kredh on 2014-06-20 11:32
I just tried and it works. The trouble is, automatic language switching should perhaps remain independent from the letter and puctuation names. If the information can be deduced from the synthetizer, couldn't it just use it without the "automatic language switching" enabled?

@nvaccessAuto

Comment 5 by jteh on 2014-06-20 11:54
One reason a user might not want to use automatic language switching is that a synthesiser they use does not correctly report its language, which unfortunately does happen with some synths. This is why NVDA resorts to the interface language in this case.

I understand that you choose to switch synths yourself. However, this doesn't explain why having this option enabled is a problem for you. If you're going to switch anyway, the automatic switch might be wasted, but shouldn't be problematic. Can you explain the problems this causes for you?

@nvaccessAuto

Comment 6 by kredh on 2014-06-20 12:09
There are two reasons why I don't like to enable this option:

  1. I'm using two different synthetizers (Eloquence in French and a voice from Vocalizer in English). Therefore, if I enable this option in French and it switches in English (when I browse an English website, let's say), it still is the English voice for Eloquence, which is not the one I really like in this language.

  2. When a web page contains information in both languages (and probably in other languages, as well), the synthetizer keeps on changing. And it's not always required (say, some text looks like English to it but, it's short, it works in French too, and as a matter of fact it was intended as a French text). The change of synthetizer from line to line (even on a single line) is quite disturbing, but the unconsistency is worse.

I'm not asking that it be fixed, I can imagine how hard this feature (automatic language switching) is to implement in the first place. But the symbol names could still be in the synthetizer language without it enabled, I think, if the synthetizer is explicit about the language it uses currently.

@nvaccessAuto

Comment 7 by jteh (in reply to comment 6) on 2014-06-20 12:29
Replying to kredh:

  1. I'm using two different synthetizers (Eloquence in French and a voice from Vocalizer in English). Therefore, if I enable this option in French and it switches in English (when I browse an English website, let's say), it still is the English voice for Eloquence, which is not the one I really like in this language.

If you're browsing an English site, I'm guessing you have to switch to Vocalizer manually anyway. Therefore, I don't follow why Eloquence switching to English is problematic, since you have to override it either way. What am I missing here?

  1. When a web page contains information in both languages (and probably in other languages, as well), the synthetizer keeps on changing. And it's not always required (say, some text looks like English to it but, it's short, it works in French too, and as a matter of fact it was intended as a French text).

NVDA currently only switches languages if the document explicitly specifies the language for a given piece of text. It's odd that the author intended this, even though you note this is not ideal.

But the symbol names could still be in the synthetizer language without it enabled, I think, if the synthetizer is explicit about the language it uses currently.

It can't for several reasons:
1. I seem to recall that some synthesisers explicitly specify an incorrect language. NVDA can't distinguish these cases.
2. Some multi-lingual synthesisers automatically switch between languages depending on the text. For example, an Arabic synthesiser might speak Arabic for Arabic characters but English otherwise, since these languages use very different characters. In this case, the synthesiser will always report its language as Arabic, but the user might actually prefer to have NVDA's interface in English and read English characters, etc.

If this does indeed need to be configurable, we'd need to introduce another option. I'm very reluctant to do this because this will be confusing for users and describing it is extremely difficult. This is why I want to make sure we fully understand your use case.

@nvaccessAuto

Comment 8 by kredh on 2014-06-20 12:46
It seems that fixing it would bring more trouble than anything and the bug is not that big either (if you call it a bug at all). And anyway, I realized that the same problem held true for HTML elements (like link, lists, edit fields). So in this case, changing the NVDA language remains the best solution (and changing the NVDA language through profiles is probably not urgent and perhaps not even possible).

Anyway, I think it's a rather individual need and won't benefit much for the community itself, considering the time that would be necessary to fix it. So I think you can close this ticket.

@nvaccessAuto

Comment 9 by jteh on 2014-12-02 06:06
We're going to add a new option called something like "Speak symbols using voice language". If Automatic language switching is enabled, this will be force enabled too.

@nvaccessAuto

Comment 10 by Michael Curran <mick@... on 2014-12-16 03:50
In [9bfd3ae]:
```CommitTicketReference repository="" revision="9bfd3aeb9d8d4581957848026c29ea233e557c60"
Merge branch 't4210' into next. Incubates #4210

Changes:
Added labels: incubating
@nvaccessAuto

Comment 11 by vgjh2005 on 2014-12-16 12:32
Hi:
I like this feature very much. Thanks for developing this function.
I am using vocalizer express to test this new feature. I find a problem at this time.
Step to reproduce:
1.Uncheck Trust voice's language when processing characters and symbols;
2.Checked Detect text language based on unicode characters (experimental)
and Ignore numbers and common punctuation when detecting text language (experimental) in Automatic language switching settings dialog;
3.Set the default synthesizer to tiantian that is a Chinese voice.
4.Paste the symbol ° in notepad;
5.Press arror key to read it.
expective: read as 度
actually: Read as degrees
Why? I don't decide that this is a bug, however, that I cannot realize this function is also possible. Please let me know.
Thanks!

@nvaccessAuto

Comment 12 by jteh on 2014-12-16 12:38
Unless I'm missing something, this makes sense and is exactly what this feature is supposed to do. You've chosen not to trust the voice's language, so unless the document specifically indicates otherwise, NVDA will use NVDA's interface language for symbols rather than asking the voice which language to use. If you want to trust the language reported by the voice, you need to enable the option.

@nvaccessAuto

Comment 13 by vgjh2005 on 2014-12-16 17:55
Hi:
I've known it for comment above. I think I should tell you that my interface language is simplified Chinese. When I unchecked "Trust voice's language when processing characters and symbols",the symbol ° should be read in Chinese. But actually it was read in English.
I think that the reason is that vocalizer express addon do language switching by itself, and the new option is not effect in vocalizer express. Thanks!

@nvaccessAuto

Comment 14 by jteh on 2014-12-16 23:25
You are correct; Vocalizer's auto language switching stuff is not at all integrated with NVDA itself, so NVDA is completely unaware of it and can't affect it in any way.

@nvaccessAuto

Comment 15 by Michael Curran <mick@... on 2015-01-04 23:38
In [dcd5874]:
```CommitTicketReference repository="" revision="dcd58740de5b6fecb425af336a87c9091d34d938"
Merge branch 't4210'. Fixes #4210

Changes:
Removed labels: incubating
State: closed
@nvaccessAuto

Comment 16 by mdcurran on 2015-01-04 23:39
Changes:
Milestone changed from None to 2015.1

@nvaccessAuto

Comment 18 by leonarddr on 2015-02-16 21:36
I wonder, shouldn't the interpunction/symbol pronunciation prefferences dialog respect this option, I.E. load the symbols of the corresponding voice language when this option is enabled? Things can be very unclear when one is editing symbol pronunciation rules which aren't applied due to the selected voice talking another language. I wouldn't mind about this if trust voice language wasn't enabled by default , but now, it seems an issue to me.

@nvaccessAuto

Comment 19 by jteh on 2015-02-18 03:55
I agree this is a problem which should be fixed. However, this is not new. Previously, the same occurred when you had automatic language switching enabled (which was the default). Filed #4930 for this.

@nvaccessAuto nvaccessAuto added this to the 2015.1 milestone Nov 10, 2015
@surfer0627
surfer0627 commented Jun 24, 2016 edited

Hi,
Some zh-TW users report:
Checked "Trust voice's language when processing characters and symbols" caused NVDA to use zh_CN's characters and symbols description.
expected: use zh-TW's files

@jcsteh

That suggests the voice reports it is zh_CN instead of zh_TW, which suggests a bug in the voice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment