Redesign profile handling in NVDA so users can lock / unlock them

[Adriani90]

Is your feature request related to a problem? Please describe.

Currently, changing settings in NVDA when more than one profile is created becomes complex, especially when more than 30 profiles are used. Settings have to be changed regularly on many profiles and this cannot happen at the same time so it's very inefficient.
In case of audio settings, e.g. the other apps volume adjuster does not work as expected, because the setting is profile dependent and so there is no way to change volume of all other apps except NVDA at once, because this has to be done on every profile for every application.
This problem is widely described in #17124 and the solution is currently not fully solving #16052, leading to wrong explanations in the user guide.
Other settings that are problematic with the current profile approach are e.g. the speech rate which often needs to be changed only temporarily, but sometimes also on a global scale and not on a profile scale.
Also ther are valid use cases when screen curtain should remian global and there are use cases when it should be profile based (see #10476 for more details).

Describe the solution you'd like

In #10156 the community came to the conclusion that introducing a lock/unlock feature to every profile is the best solution and easiest to implement.
Locking a profile means the parameter written to the profileName.ini cannot be changed anymore and there is nothing else written to the profileName.ini, but to the global configuration instead.

User story:

1. A user created 10 profiles
2. A user wants to change the speech rate globally
3. The user wants to change reporting of elements in document formating settings globally
4. The user wants to change table related reportings in document formating settings for a profile only.
5. The user want to use the applications volume adjuster and the sound split feature globally as this is the best user experience and coresponds to the descriptions in the user guide.
6. The user wants to change punctuation level on a profile only
7. The user want to change the synthesizer voice on 2 of the 10 profiles
8. The user wants to enable screen curtain globally accross all profiles
9. The user opens the profile manager after 10 profiles are created
10. In addition to the current list of profiles status, an additional checkable list is displayed (e.g. lock / unlock profiles list) in which every profile item name is preceeded by the string "lock" and can be enabled via its checkbox. E.G. the profile items in this checkable list would look like:

• Lock firefox profile checkbox checked
• Lock WinWord profile checkbox checked
• Lock Outlook profile checkbox checked
  By default all profiles are locked / all checkboxes in the checkable list are enabled, meaning that settings changes are always global) The parameter of the settings are not written to the profileName.ini file.

11. The user unlocks some profiles by disabling the coresponding profile check boxes.
12. From now on, every setting that the user changes is only applied for the unlocked profiles and the parameter is written to the profileName.ini files of the unlocked profiles.
13. The user can lock the profiles again as soon as the changes have been done, and the coresponding profileName.ini files become protected.

Conclusion

on locked profiles, NVDA would use a combiation of settings parameters written to the profileName.ini file before, and the remaining global settings parameters which are not written to the profileName.ini file.

Problem

What happens when users focused e.g. Firefox and changed a setting (e.g. speech rate) on its profile which was unlocked before, and change that setting again after the profile was locked? In that case we would have two speech rate settings parameters, one on the global configuration and one in the Firefox profile.
Does NVDA prefer the global setting? Or does the parameter which was written to the profileName.ini prevail?

My suggestion to the problem above is:

• In case the user changed the same setting (e.g. speech rate) both on the locked and the unlocked profile, let NVDA always prefer the global parameter when the profile is locked and the one in the profileName.ini when the profile is unlocked.
• Provide a keystroke to unlock / lock the profile of the currently focused application (e.g. nvda+shift+p) in order to switch on the fly between use the speech rate parameter written in the profileName.ini file and use the speech rate parameter written to the global configuration.
• Provide an additional keystroke to lock all profiles at once in order to efficiently change a setting globally in case many profiles were unlocked before (e.g. nvda+shift+ctrl+p).

Describe alternatives you've considered

Value based locking feature

While the proposed solution above is focused on adding settings parameters to the profile ini files when they are unlocked, the alternative would be a value based locking feature:

• When profile ini is locked, settings parameters can be added but their values are not saved when the users change tem, still they impact the profile ini file.
• It would need a combo box for every profile to specify when the setting should be saved when the profile is locked (e.g. after NVDA restart).
• When profile ini file is unlocked, changed values are saved in the profile ini file according to the coresponding setting in general settings category (e.g. after NVDA exit).

Drawbacks:

• settings are not saved anywhere when profiles are locked and they revert every time you change window with alt+tab which would cause confusions.
• The UX would need a much more complex development because you have to define a combo box for every profile to decide when its settings values should be saved as long as it is locked.

Including or excluding whole settings categories to profiles (same as VO or Orca)

This would allow for every profile to include or exclude settings categories, .g. via a checkable list in the profile dialog. This means every setting changed in the included category (e.g. braille settings) would go into the profile ini file when focusing the app with the profile triggered. When the category is excluded, changing settings in the coresponding category would be saved only in the global config.

Drawbacks:

• Higher development efforts needed, because categories of settings in settings pannel would have to be in sync with what users include and exclude in or from profiles in the profile manager.
• It is not really possible to communicate which profiles a settings category will affect when focusing the category in the settings pannel, so it will become intransparent which categories go in which profiles (especially when you have 30 profiles)
• The profiles ini files become inefficiently leaked with settings categories where only one setting is regularly changed on a profile basis.

Additional context

This feature would introduce the risk that users get confused because some of their settings are changed after an NVDA update since the profiles get locked (e.g. if they changed the speech rate both on a profile and in the global configuration).
However, this is not a big problem, users would just have to unlock their profiles in the profile manager dialog manually, or via keystroke, and the previous behavior is restored.

Additional things to consider when implementing this:

• When a profile is locked, and an user opens the settings pannel while focusing an app with that locked profile (e.g. firefox) the Firefox profile should not be announced on the settings category, because settings parameters and their values are not impacting that profile while it is locked.
• Instead, NVDA should announce "global profile" or something similar.

[Adriani90]

cc: @CyrilleB79, @XLTechie, @mltony, @Simon818, @rperez030, @pitermach, @TechHorseG, @Neurrone among people who would like this flexibility of deciding when global parameters and profileName.ini parameters are used.

[mltony]

@Adriani90, Regarding your example with Firefox and speech rate. One more feature I wish could be included is to clear Firefox-specific speech rate and make it follow global speech rate once again without deleting Firefox profile.
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox - but correct me if I'm wrong. Currently you would have to either drop the entire Firefox profile or manually edit ini files, which is way too tedious. I wish there was an easier way, but I am struggling to come up with a good UX concept for this feature that would be user-friendly.

[Adriani90]

One more feature I wish could be included is to clear Firefox-specific speech rate
This would be useful when you happen to have adjusted speech rate in Firefox by mistake. In my understanding once this happens - there is no easy way to revert to global speech rate for Firefox.

There are two requests here:

1. Reverting speech rate because you changed it accidentally
   Solution: if you didn't restart NVDA or you didn't save by pressing nvda+ctrl+c, then you can revert to the lastly saved setting by pressing ctrl+nvda+r, so the speech rate resumes to the value when you saved it for the last time. This should solve your issue actually. But yeah, if you want to make sure that only the speech rate is resumed, then have a look at Add temporary speech rate setting #16431, Jaws provides this already. The speech rate resumes as soon as you change the window and return back to it.

2. Firefox profile speech rate follows global speech rate
   Solution: We have currently a list of profiles in the profile manager, this could be changed to a list similar to the addon store where every profile item would have a context menu. When opening the context menu of a profile item, following menu items could be available:

• Follow global configuration (becombes "unfollow global configuration when following it). It is only available for unlocked profiles.
• Mannualy activate
• Rename
• Delete

When following global configuration which would ofcourse work only on unlocked profiles, the settings changes on the global config would also be reflected in the Firefox profile ini file.

[Adriani90]

Note: if the decision is to have context menu on profile items, I would still vote for the checkable list of lock / unlock profiles for efficiency reasons. It would be a mess to open the context menu on every of the 30 profiles to unlock them.

[SaschaCowley]

@Adriani90 would that not essentially be the same as deleting the profile and starting again? If we don't tell NVDA which settings you want to follow the normal configuration, then that option would essentially be telling it to reset the configuration to the normal configuration.

Personally, though more complex, I think the VO (and from memory Orca) solution of selecting categories to include in profiles makes the most sense. If a category is selected to be included, the any configuration from the profile in that category is used, otherwise the normal config values are used. If a category is excluded, the normal config is used.

[Adriani90]

would that not essentially be the same as deleting the profile and starting again? If we don't tell NVDA which settings you want to follow the normal configuration, then that option would essentially be telling it to reset the configuration to the normal configuration.

Not really, deleting a profile means you start really from scratch. Following the global configuration would practically happen only on a temporary basis, when you want to change just some settings but you don't want to focus three different applications.
In my suggestion you could open the context menu of 3 different profiles, choose to follow the global configuration, and you change the global configuration while this would reflect on three profiles at the same time. This is very efficient way of profile handling compared to what we have now or compared to VO or Orca. If you unfollow the global config, then the profiles are handled separately again.

Personally, though more complex, I think the VO (and from memory Orca) solution of selecting categories to include in profiles makes the most sense. If a category is selected to be included, the any configuration from the profile in that category is used, otherwise the normal config values are used. If a category is excluded, the normal config is used.

To me this sounds too general and doesn't really meet users expectations which we saw in different issues related to profiles. Adding a whole category to a profile is far too much. Users need more flexibility to adjust single settings on a profile basis or on a global basis, and this should ideally happen on the fly, not being tied to a whole included or excluded category.
The UX in VO and Orca is not satisfactory at least in my view, because you have to cope with lots of including and excluding activities.

Whereas the proposed UX would allow for a very quick lock / unlock feature and this allows more flexibility, especially when doing it via a key stroke.

[SaschaCowley]

@Adriani90 how does your proposal address your point 2 "Firefox profile speech rate follows global speech rate"? I.e. how does the user tell NVDA that they want to delete speech rate from their firefox configuration permanently?

[seanbudd]

Converted to a discussion until a more clear UX is resolved

[Simon818]

My suggestion for this (which I still believe to be the simplest):

• Profiles can indeed be unlocked or unlocked, and a profile is unlocked by default.
• When a profile is unlocked, any settings that are changed while that profile is active will be saved to that profile. That means new parameters will make their way into the INI file.
• When a profile is locked, those parameters can still be adjusted in the profile but any new parameters are not saved to the profile.
• For instance, I have a text adventure game profile that increases speech rate from 75 to 85, turns off typing interrupt, and sets punctuation to "none".
• Once I've created that profile, if I lock it, changing the speech rate in my game window will still permanently change the speech rate for the text adventure profile.
• Changing speech pitch, output device, or Braille settings in the game window will change them globally since those settings were never made part of the text adventure profile before it is locked.

Here are some other proposals and why I don't think they'll work as well:

• Locking the profile should lock it completely so no settings can be changed:
  • This will cause settings changes to be unexpectedly thrown away. If you lock the game profile and you change a setting, that setting will never get saved anywhere and will revert after switching back into the window, JAWS-style. I think this is much more confusing, though I'll admit it would be easier to code.
• You should be able to choose settings categories that will apply to each profile:
  • I don't want to have to think about where a setting is in order to add it to my profile. I don't want to have to choose. I just want to change the settings and decide when I've changed enough of them.
  • If I change a setting that happens to be a part of the same category that's already in the profile, and the profile is active, it will still "leak" into the profile permanently--in other words, the same problem as we're trying to solve, but on a smaller scale.
  • There's no guarantee the settings someone wants to change will be in the same one or two categories. Maybe you want a profile with five unique settings and they're in five categories. Now that's five times the potential settings leakage and we've barely solved the problem being discussed.
  • Big important settings like the current Braille display, current synthesizer, and current audio device could easily leak into the profile if the right categories are selected. This can result in really confusing scenarios where someone's primary output method is suddenly not working because they inadvertently changed it while the profile was active and then switched out of the window. This exact thing happens to me constantly because I switch between Braille displays and audio output devices.

[Adriani90]

@SaschaCowley wrote:

how does your proposal address your point 2 "Firefox profile speech rate follows global speech rate"? I.e. how does the user tell NVDA that they want to delete speech rate from their firefox configuration permanently?

Profile speech rate follows global config speech rate should not allow for deleting the speech rate from profile ini file, this is indeed not possible on global config as well unless you delete the ini file as you pointed out. But @mltony doesn't really want to delete the speech rate from the profile ini file, he does it because there is no other way to resume speech rate. Resuming speech rate is covered by point 1 above (temporary speech rate setting as proposed in #16431). Point 2 is another request and is actually tackling rather other problems but not particulary the one about resuming speech rate.

@Simon818 thanks for your feedback, let's try to avoide repeating what is already described and discuss on point what we agree on or what we don't agree on. You wrote:

a profile is unlocked by default.

I proposed profiles to be locked by default given our experience in the community that people more often change settings on a global basis tahn on a profile basis. And this was also what was agreed on in #10156. I still think this would make sense.

When a profile is unlocked, any settings that are changed while that profile is active will be saved to that profile. That means new parameters will make their way into the INI file.

That's what I described in the initial description.

When a profile is locked, those parameters can still be adjusted in the profile

I don't really agree with this, because the settings would then restore everytime you leave the window with alt+tab and that would rather cause confusions. I think saving them in the global config instead is a better option and according to my understanding was also agreed upon in #10156.

• For instance, I have a text adventure game profile that increases speech rate from 75 to 85, turns off typing interrupt, and sets punctuation to "none".
• Once I've created that profile, if I lock it, changing the speech rate in my game window will still permanently change the speech rate for the text adventure profile.

This would cause the problem of settings being resumed to easily. While this makes sense for speech rate as explained in #16431, other settings should not be resumed that quick when changing windows with alt+tab or so (e.g. changing audio output). That's why the only way is to save them into the global config when the profile is locked.
But yeah it is ofcourse debatable whether all settings should be temporary for the locked profile, that is they would always resume to the state when the profile was locked after you change the window to another application and return back. But then it is confusing when you have 10 profiles and would like to change speech rate globally. The easiest way is to lock all 10 profiles and change the speech rate globally. You only need to unlock the profiles from time to time when you want to adjust some settings.

• Changing speech pitch, output device, or Braille settings in the game window will change them globally since those settings were never made part of the text adventure profile before it is locked.

That's what I've also described in the initial description above.

• Locking the profile should lock it completely so no settings can be changed

That's what has been agreed on in #10156 for the profile ini file.

◦ This will cause settings changes to be unexpectedly thrown away.

Not really, they are then saved to the global config.

◦ I don't want to have to think about where a setting is in order to add it to my profile. I don't want to have to choose. I just want to change the settings and decide when I've changed enough of them.

You would have to think about it too when you add whole categories to the profile, and the UX would get more complex and not really manageable. What you say is already possible with the lock feature. When you decide there were enough settings changed for that profile, you just lock it. That's what was agreed on in #10156.
If I add 3 categories to the firefox profile, but I change only one setting of those categories on a regular basis, what is the point of it? I will forget anyway after a while that I added 3 categories on that profile. I rather think that in Firefox I often don't need tables to be announced, so that's quite clear that this is definitely the setting I change on a profile basis regularly.

If I change a setting that happens to be a part of the same category that's already in the profile, and the profile is active, it will still "leak" into the profile permanently--in other words, the same problem as we're trying to solve, but on a smaller scale.

What do you mean by smaller scale? Actually the categories proposal is on a bigger scale, and then the profile ini file is always leaked with categories where you might never change a setting on a profile basis.
I still think the lock / unlock feature based on settings parameters is a UX that's good enough to cover all the problems described above.

◦ There's no guarantee the settings someone wants to change will be in the same one or two categories. Maybe you want a profile with five unique settings and they're in five categories.

Exactly that's why leaking profile ini files with whole categories is inefficient.

Now that's five times the potential settings leakage and we've barely solved the problem being discussed.

I don't understand this part. If I have 5 settings which I change on the unlocked profile ini file, why are they 5 times leaked in there? The proposal is to ad the coresponding settings parameters once to the unlocked profile when I change them on that profile for the first time. Their values are then adjusted accordingly when I change them on the unlocked profile afterwards.

◦ Big important settings like the current Braille display, current synthesizer, and current audio device could easily leak into the profile if the right categories are selected. This can result in really confusing scenarios where someone's primary output method is suddenly not working because they inadvertently changed it while the profile was active and then switched out of the window. This exact thing happens to me constantly because I switch between Braille displays and audio output devices.

So it seems you are not keen on adding whole categories to the profile ini file in the end. These confusions is what I was trying to explain above as well. If you add the whole category to a profile, such things can occur very often.

[Adriani90]

@SaschaCowley what is the purpose of deleting a settings parameter permanently from a profile ini file? If If that's done, then the global setting parameter would apply. This would also be the same when I choose "follow global profile" from the context menu of a profile, and change e.g. the speech rate on the global config afterwards. In that moment, the speech rate in the profile ini file would change, and I am still flexible enough to unfollow the global config and adjust the speech rate separately on a profile basis, that's the advantage of it.
Deleting the speech rate completely would probably result in adding it again when the user adjusts this setting again on a profile basis. In my view it is more efficient to adjust values back and forth instead of repeatedly adding or deleting the whole setting parameter. But maybe I am wrong.

[XLTechie]

@Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156.

1. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button.
2. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock.
   * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made.
   * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added.

Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution.

That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed.
In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved, and so not written anywhere. In the parameter lock idea, they would be written to the profile.

Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile.

The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue.

[Adriani90]

Ok in this case the discussion seems to get stuck. I tried to summarize and interpret the points agreed on in principle, so that the underlying problems are solved in a user friendly way. It seems you rather expect a 100% summary of the old discussion. Please proceed with your version then, because this one is again blown up already and the arguments you raised are not really bringing this forward in a constructive way.Von meinem iPhone gesendetAm 20.11.2024 um 12:45 schrieb Luke Davis ***@***.***>: @Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock. * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made. * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added. Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution. That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed. In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved. In the parameter lock idea, they would be written to the profile. Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile. The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

By the way, whether a profile has a lock button or is a checkbox itself is really such a small point with no real effect on UX. I wonder why you want to open up the discussion again on such small things, but maybe there are arguments which speak for a button for each profile instead of a checkable list. If there are, please elaborate on the advantages of having a button for each profile and the disadvantage of the checkable list.Von meinem iPhone gesendetAm 20.11.2024 um 13:46 schrieb Adriani Botez ***@***.***>:Ok in this case the discussion seems to get stuck. I tried to summarize and interpret the points agreed on in principle, so that the underlying problems are solved in a user friendly way. It seems you rather expect a 100% summary of the old discussion. Please proceed with your version then, because this one is again blown up already and the arguments you raised are not really bringing this forward in a constructive way.Von meinem iPhone gesendetAm 20.11.2024 um 12:45 schrieb Luke Davis ***@***.***>: @Adriani90 Respectfully, I do not find this to be an accurate summary of the community conclusion in #10156. At no point, was it proposed to have a list of locked/unlocked profiles. It was universally stated that each profile, when chosen as active, should have a lock/unlock button. There were two primary alternatives discussed in the latter half of the issue: a parameter lock, vs. a value lock. * In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made. * In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added. Several difficulties exist with the value lock idea, as adequately stated by others in that issue (especially #10156 (comment)), that make the parameter lock be the preferred (and more user friendly), solution. That is my reading of the issue--no locked profile list, and the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed. In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved. In the parameter lock idea, they would be written to the profile. Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution. Nobody asked for that, and it seems contrary to the reason someone creates a profile. The concern raised by @mltony is of course valid, but seems outside the scope of this issue. Issue drift is a big problem on this topic, because there are a lot of tangential problems associated with profiles. But IMO, that one should be its own issue. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[Adriani90]

@XLTechie wrote:

• In a value lock, as proposed by @CyrilleB79, after a user edits some parameters (e.g. speech rate, announce line numbers, synth selection), and locks the profile, no new parameters could be added to the profile, and no changes to the values of those parameters could be made.

This is not a feasible solution, and @CyrilleB79 as well as others agreed rather upon a parameter based solution which I proposed here. Things on which we didn't agree were not part of the request here. But I've added them all now to the alternatives part in the initial request.

[Adriani90]

@XLTechie wrote:

• In a parameter lock, as proposed by @Simon818, when locked, the values of already included parameters could still be changed, but no new parameters could be added.

Again this is what I've described above in the initial description.

[Adriani90]

the statement of "there is nothing else written to the profileName.ini, but to the global configuration" is not representative of either of the main solutions discussed.
In the value lock idea, other value changes to parameters already in the profile, would have to remain unsaved, and so not written anywhere. In the parameter lock idea, they would be written to the profile.
Lastly, having profiles be locked at creation by default was never raised in the issue that I noticed, so shouldn't be part of the summarized solution.

That's not true. In #10156 (comment)
and
#10156 (comment)
even you and also the other person both have the understanding that having settings not reflected in the profile ini when it is locked is the prefered solution. Letting all profiles unlocked by default would not reflect this. Your problem of users being confused is even described here in the additional context in the initial description.

Regarding saving them to global config when profile is locked, this is the only way to solve @Simon818 problem in #10156 (comment) having the proposed feature in mind. Otherwise his settings would be thrown away after pressing alt+tab, and this is definitely not the intended behavior.

[Adriani90]

@SaschaCowley I edit now the alternatives of the discussed things in the initial description, so NV Access can decide on a prefered UX design.
The points about cleaning profile ini file permanently vs. follow / unfollow global config can be discussed in another issue, as well as the issue about temporary speech rate setting which is better discussed in #16431.