Bug 965371 - RFE: Make attention key shortcut configurable
RFE: Make attention key shortcut configurable
Status: CLOSED UPSTREAM
Product: Zanata
Classification: Community
Component: Component-UI (Show other bugs)
3.0
Unspecified Linux
low Severity medium
: ---
: ---
Assigned To: Michelle Kim
Zanata-QA Mailling List
: screened
Depends On: 786630 961564
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-21 00:30 EDT by David Mason
Modified: 2015-07-28 23:35 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 961564
Environment:
Last Closed: 2015-07-28 23:35:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description David Mason 2013-05-21 00:30:00 EDT
+++ This bug was initially created as a clone of Bug #961564 +++

Separating the remaining part to a different bug to allow QA of current implementation.

> The ability to change the key shortcut from Alt+X to a different combination has not yet been implemented.

Make the attention key configurable as a persistent user setting.

 - the selector to change the shortcut should be at the top of the key shortcut summary.
 - the shortcut should change as soon as it is selected, and automatically persist to the server without additional input.
 - the key shortcut summary should immediately reflect the change of attention key in the shortcut summary table.
Comment 1 David Mason 2015-03-25 01:15:39 EDT
This is an important part of the attention key shortcut feature - the whole point of the feature is to allow users to work around key shortcut conflicts with browser or input method editor shortcuts.

This should have been scheduled immediately after the attention key shortcut was implemented. We should get this done soon since it has low complexity and would prevent having a half-implemented feature.
Comment 2 Luke Brooker 2015-03-25 20:29:55 EDT
I think the better solution to this would be to have better shortcuts in the first place and not needing an attention key.

If we had custom shortcuts, what happens if the user sets it to a Zanata shortcut that is already conflicting?
Comment 3 David Mason 2015-03-27 22:23:48 EDT
(In reply to Luke Brooker from comment #2)
> I think the better solution to this would be to have better shortcuts in the
> first place and not needing an attention key.
> 
> If we had custom shortcuts, what happens if the user sets it to a Zanata
> shortcut that is already conflicting?

That would defeat the purpose of the attention key shorcut. The problem that the attention key aims to address is that Zanata can have key shortcut conflicts from:

 - operating system
 - browser
 - input method editors (IMEs)

The first 2 are common to any web app, but the last is of critical importance to Zanata since use of IMEs is part of the expected core workflow for translators.

Basically we have to either find key shortcuts that do not conflict with any known IME, or we should provide a customizable key that translators can use to work around any conflict. I do not think we have the capacity to reliably assess which key shortcuts will conflict with every IME that a translator might use.
Comment 4 Zanata Migrator 2015-07-28 23:35:56 EDT
Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-339

Note You need to log in before you can comment on or make changes to this bug.