Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 965371

Summary:	RFE: Make attention key shortcut configurable
Product:	[Retired] Zanata	Reporter:	David Mason <damason>
Component:	Component-UI	Assignee:	Michelle Kim <mkim>
Status:	CLOSED UPSTREAM	QA Contact:	Zanata-QA Mailling List <zanata-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	3.0	CC:	aeng, djansen, hpeters, lbrooker, sflaniga, zanata-bugs
Target Milestone:	---	Keywords:	screened
Target Release:	---
Hardware:	Unspecified
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	961564	Environment:
Last Closed:	2015-07-29 03:35:56 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	786630, 961564
Bug Blocks:

Description David Mason 2013-05-21 04:30:00 UTC

+++ 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 05:15:39 UTC

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-26 00:29:55 UTC

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-28 02:23:48 UTC

(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-29 03:35:56 UTC

Migrated; check JIRA for bug status: http://zanata.atlassian.net/browse/ZNTA-339