New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Synth handler/settings ring: look up normalized names of common voice settings to help with translation contexts #5185
Comments
Comment 1 by nvdakor on 2015-06-27 04:18 |
Comment 2 by jteh on 2015-06-29 00:59 As you suggest, the best solution is to add a new attribute to SynthSetting. I guess we can have displayName and displayNameWithAccelerator, where the latter is used for the GUI and contains the accelerator. (The former shouldn't specifically mention the ring, as it might be used for other things in future where accelerators aren't wanted.) i18nName could be mapped to displayNameWithAccelerator for backwards compatibility. Unfortunately, this will require most translators to do a lot of unnecessary translation, but I don't see a way around this. |
Comment 3 by nvdakor on 2015-06-29 01:20
|
Comment 4 by Joseph Lee <joseph.lee22590@... on 2015-06-29 02:15
|
Comment 6 by jteh on 2015-07-03 07:35 In SynthSetting:
Please put a code doc comment on the line above this stating that it's deprecated. Something like this will do: In
It's best to only pass keyword arguments as keyword arguments; e.g. You use "synth settings ring" as the gettext message context. While I think it's okay to have the translators comments say that (since it's only currently used for the ring), it could also be conceivably used in other places where we want to refer to synth settings without the accelerator. Therefore, I'd prefer this be "synth setting" or "synth setting without accelerator" or similar. If displayName is None, you check for this in the settings ring code and do the replacement there. I wonder whether we should instead do this in the SynthSetting constructor. Thoughts? Thanks again. |
Comment 7 by nvdakor (in reply to comment 6) on 2015-07-03 07:45
Sure.
I wrote it like that because of the scope of this ticket, but I do understand that this could be used in other situations, hence will change it.
I don't know about that (you know more about this than I do). |
Comment 8 by Joseph Lee <joseph.lee22590@... on 2015-07-03 08:01
|
Comment 9 by James Teh <jamie@... on 2015-07-09 07:46
Changes:
|
Comment 10 by jteh on 2015-07-09 07:48 Note for merge to master: Squash this to one commit. Add entry in Changes for Developers. |
Comment 11 by James Teh <jamie@... on 2015-07-24 06:43
Changes:
|
…ing now has separate displayNameWithAccelerator and displayName attributes to avoid reporting of the accelerator in the synth settings ring in some languages. Fixes #5185.
- Deprecated code removed: - PR #6878: `speech.REASON_*` constants, `controlTypes.REASON_*` should be used instead. (issue #6846) - PR #6877: `i18nName` for synth settings, `displayName` and `displayNameWithAccelerator` should be used instead. (issues #6846, #5185) - PR #6876: `config.validateConfig`. (issues #6846, #667) - PR #6875: `config.save`. (issue #6846) - PR #6914: Support Windows Calculator on Windows 10 Enterprise LTSB (Long-Term Servicing Branch) and Server. (issue #6914) - PR #6987: Reduced the chance of configuration file being corrupted when Windows shuts down. Configuration files are now written to a temporary file before replacing the actual configuration file. (issue #3165)
Reported by nvdakor on 2015-06-27 03:20
Hi,
Spin-off from #5100:
Consider the following scenario: a user uses NvDA in a language other than English, such as Japanese, and uses synthe settings ring commands to manipulate voice settings. Normally, the user would hear only the translated portion of the message, but for some languages, the accelerator used in voice settings dialog is also spoken.
Problem: This is because commonly manipulated settings are stored in synth driver handler, and the translatable strings in there are also used in voice settings dialog.
Proposed solution: Modify i18nName function as follows:
Impact and use cases:
Additional comments are appreciated. Thanks.
Blocking #5100
The text was updated successfully, but these errors were encountered: