Fix a bug causing NVDA to use the wrong language when announcing selected/unselected symbols.

[mikolysz]

Summary of the issue:

When languages of the currently selected voice and of NVDA itself
differ, NVDA uses the voice language when announcing typed and erased
characters. This wasn't the case when selecting by character, the NVDA
language was always used.

Description of how this pull request fixes the issue:

There was a function called "getCurrentLanguage" already present in speech.py. It just needed to be used instead of LanguageHandler to determine the locale used when reading the selected text.

Testing performed:

I have tested this on the english language version of NVDA and polish espeak and I can confirm that it works correctly now.

Change log entry:

Bug Fixes
NVDA now uses the correct language when announcing symbols when text is selected.

[feerrenrut]

Since there is no bug for this, could you please update this with steps to reproduce. Thanks.

[mikolysz]

Sorry if this is a duplicate, but it seems my email reply didn't go through, at least I can't see it on the page.
steps to reproduce:

1. set your NVDA language to english.
2. switch to espeak.
3. set your voice to something different than english.
4. type a symbol, i.e. ' tick or ; semicolon and note what espeak says (it will read the symbol in the right language). If you for example switch it to polish, it will read the polish pronunciation for that symbol.
5. Press shift + left arrow to select the symbol, espeak will announce the english name of the symbol and the word selected. It should announce the name in the selected language, as it does when typing, erasing or reading, but it won't. I don't think it's exclusively an espeak problem, using the wrong language (by NVDA) seems to be the cause and this PR fixes that.

[feerrenrut]

Thanks for adding that.

[feerrenrut]

Overall this looks ok. However this causes the unit tests to fail, so this will need to be updated before we can accept the PR. To run the tests run scons tests.

Also, I would like this to be tested with the new version of espeak that is currently incubating (on the next branch)

[mikolysz]

I've just tested it with the next branch and, as expected, it works exactly the same because it's an NVDA issue that can be observed when using espeak but it's not unique to one synthesizer, it can be observed with other synths too, for example ivona2 on sapi5. That synth also communicates to NVDA about what language it speaks so the issue affects it too. I've provided my instructions for espeak because every NVDA instance has one available but this was only meant as an easily-reproducible example. I'l look into the unit tests too. At a first glance, it seems that now a synthesizer is required to determine the language and the tests fail because it's not available in the testing environment. Providing a mock and rewriting the relevant method so that it can handle this case properly and revert to the old behavior when needed seem like good approaches to solve this problem.