Open mohdshara opened 7 years ago
I'm not sure I understand the request. Could you please outline the steps taken to demonstrate the current behaviour, and explain how you would like NVDA to behave instead?
When I use a recent next
build of NVDA I get the following behaviour:
Hi.
answers inline:
I'm not sure I understand the request. Could you please outline the steps taken to demonstrate the current behaviour, and explain how you would like NVDA to behave instead?
When I use a recent |next| build of NVDA I get the following behaviour:
automatic language switch and changing synth
- Set Synth to SAPI5
- Ensure "automatic language switch" is checked in "voice settings dialog"
- Set Synth to espeak
- "automatic language switch" is checked.
- Uncheck "automatic language switch"
- Set synth to SAPI5
- "automatic language switch" is uncheck
when I switch to sapi 5 in step 4 above I expect automatic language switch to be checked because that's how I configured that synth. for some synths automatic language switch is not desirable / problematic. For example, because many websites don't use language markers correctly, eloquence tends to read English text written in a site originating from Germany, for example, in English. When switching to Vocalizer I always want automatic language to work because it handles mixed content correctly in most cases.
automatic language switch and changing profiles
- Create two profiles, "temp1" and "temp2"
- Activate profile "temp1"
- Ensure that "automatic language switch" is unchecked
- Activate profile "temp2"
- Ensure that "automatic language switch" is checked.
- Activate profile "temp1"
- Note that "automatic language switch" is unchecked
- Activate profile "temp2"
- Note that "automatic language switch" is checked.
—
yes, you're right. don't know why it didn't work for me that way before. so creating 2 profiles solves this problem for me somehow.
You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/nvaccess/nvda/issues/7107#issuecomment-299092258, or mute the thread https://github.com/notifications/unsubscribe-auth/AGQl_OeMm8GzXaPMB0ZdP5xlO2zbqbN1ks5r2U1rgaJpZM4NKKrT.
@feerrenrut do you understand the request now? any comments?
I think we still need to clarify the use case here slightly. The behaviour you are seeing is intentional, but that's not to say it cant be changed. I understand that its a little confusing that some of the options in the voice settings dialog are tied to the synthesizer selection, and some are not. However I think we need to understand why its important to have a different setting for each synthesizer, rather than a single setting that affects all. For instance, I think we can agree that it would be annoying for users have to set the "symbol/punctuation level" for each synthesizer.
Is it just vocalizer where having the automatic language switching setting always on would be useful? Can you describe what vocalizer does when handling websites that incorrectly use language markers with automatic language switching turned on? And can you describe the same, but with automatic language switching turned off?
as long as we agree that it may be confusing that some options have to be synth specific, then we need to establish why automatic language switch should be one of those options. for Vocalizer, it works by detecting the uni code range of characters and then it decides which voice should speak what. you have to specifically set "Detect text language based on unicode characters" to on in its configuration. however that is not enough if you have "automatic language switch disabled. For acapela for example, it decides what voice to use regardless of what that option is set to. A big percentage of users in this part of the world have to work on text in both English and Arabic at any given moment. On a different thought, I am not sure if the planned speech refactor will make this request less important, since it will let us set a specific synth of each language. When #2990 incubates, if it ever does, this request will definitely become irrelevant.
Yes I think #2990 will help here. But either way I think its worth defining a use case here, which we can feed into #2990 when we get to it.
So if I understand correctly, the language switching in Vocalizer controlled by the Vocalizer setting "Detect text language based on unicode characters" only works well if you also have "automatic language switch" enabled in NVDA.
So now I would like to understand why you would like to have "automatic language switch" disabled for a different synthesizer?
Perhaps we can word it like a user story, can you help me complete it? (or if I have some part of it wrong please correct it)
As a user who regularly works with multiple languages, I can configure one synthesizer to have "automatic language switch" enabled, and a second synthesizer to have the same setting disabled. This is so that I can ....
"So if I understand correctly, the language switching in Vocalizer controlled by the Vocalizer setting "Detect text language based on unicode characters" only works well if you also have "automatic language switch" enabled in NVDA." very correct. "So now I would like to understand why you would like to have "automatic language switch" disabled for a different synthesizer?" Eloquence, for example, switches to German in an English section of a a German website that doesn't use the correct language codes. or to put it it differently, I Always don't want to hear my synthesizer speak in a language that I don't understand, specially if it guesses the correct language wrong most of the time. "As a user who regularly works with multiple languages, I can configure one synthesizer to have "automatic language switch" enabled, and a second synthesizer to have the same setting disabled. This is so that I can put up with my screen reader not guessing the correct language to speak, weather that is because the author of a document has authoring error, or weather NVDA currently does not use other methods to guess the correct language other than depending on a correctly coded document. In a perfect world, documents are always marked with the proper language codes.
"I understand that its a little confusing that some of the options in the voice settings dialog are tied to the synthesizer selection, and some are not." Perhaps it's worth trying to find a solution for this bigger issue?
By the way, I really do appreciate your patience to understand the request.
I agree that voice settings behave differently depending on the synth you are using. On the other hand it must be taken into account that users will face more complexity if all voice settings are tied to the synthesizer. However, this should not be a show stoper for implementin it.
If I change some voice settings they persist across synthesizers and profiles. For example, switching off "automatic language switch" for Espeak would persist if I switch to sapi5 or any other synth. it would also persist across all profiles even if I switch it off while editing a manually triggered profile.