Microsoft Sound Mapper: 'translate' Microsoft Sound Mapper entry if not translated by Windows#11627
Conversation
…r output devices in case it is not translated by Windows. Re nvaccess#11349. In a summer 2020 cumulative update for Windows 10 May 2020 Update, Microsoft Sound Mapper is once again printed when asking for audio output device names but is not translated. Therefore 'translate' this entry. This change is only applicable to 2020 feature updates (May 2020 Update/20H1 and 20H2).
|
To be honest, I find this a bit overkill. If Microsoft doesn't translate Sound Mapper, that's their responsibility, and I don't think we should work around that only for translation purposes. There are accessibility issues with way more impact we're not taking because we believe it's the responsibility of the author to fix them |
|
I fully agree with @LeonarddeR. Moreover, there will probably be corner cases such as language where NVDA is not fully translated. A point that may be more important is the impact of these name changes in the config since the outputDevice is stored as a the name that was displayed (thus localized by Windows with NVDA 2020.2 / windows 10 1909). Are there also configs in the wild that have stored the empty string as output device when using NVDA 2020.2 and Windows 10 2004? |
|
Hi,
I wrote this PR after considering impact of translations, therefore labeled it as an alternative to #11616. My personal wish is that #11616 be adopted to send a reminder to Microsoft regarding checking Windows source code (in this case, audio stack library and wave out API) to make sure strings and localizations are applied from the start of a feature update deployment, or in some cases, rectified through cumulative updates.
We’ve gone through a similar debacle before (remember UIA "invalid entry" XAML markup issue in 2016?), and I have resolved to not go through a headache like that; a few weeks ago I had to ask myself whether or not I should work on #11353, with folks asking me not to implement it as it will be resolved in a future update, a situation that we are facing in September 2020.
As for audio device names from config, NVDA will do its best to catch this and use default audio channel for audio output (that is, unless some advanced audio configuration was done, Microsoft Sound Mapper will be used as a last resort).
As a final note, I have just one blunt plea for Microsoft: please give us consistency or headaches, but not both.
Thanks.
|
|
Even though the mistake is not caused by NVDA, users will view it as such. Given it is a simple fix with no downside I'd like to go ahead with this.
This is true, but we also work around lots of such issues where it is possible and doesn't require a difficult trade off. The fix in this PR isn't going to hide accessibility issues, it's just a small mistake that affects the polish of the release. Sometimes a work around will reduce the incentive for the application developer to address the core issue, and sometimes it hides an accessibility problem more generally allowing more similar problems to be created in the future and possibly even becoming the standard way of doing things, even when it is illogical and troublesome. These are the fights worth having. Not fixing this particular issue is just bad for users. Not terribly bad, but just a little bad. As @josephsl pointed out, I'm fairly confident that NVDA will handle these edge cases, but it is easy to manually test this, and it should be done to confirm. |
|
Hi, After thinking about this for a while, I agree that this PR should be greenlighted, therefore requesting closing #11616 once this one is merged into beta. Thanks. |
Link to issue number:
Closes #11616
Fixes #11349
Tweaks #11353
Summary of the issue:
Microsoft Sound Mapper is once again printed when asking for audio device names but is not translated in some languages (technically a regression from Microsoft).
Description of how this pull request fixes the issue:
Temporary workaround: "translate" Microsoft Sound Mapper if it wasn't.
Testing performed:
Tested via source copy under Windows 10 Version 2004 build 19041.508 (and corresponding 20H2 build).
Known issues with pull request:
None
Change log entry:
None
Thanks.