Closed Bug 1477816 Opened 6 years ago Closed 6 years ago

Eliminate localization errors of "Reorder Attachments" keyboard shortcut key (change Alt+X to Ctrl+Shift+X)

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(thunderbird_esr60 fixed, thunderbird62 wontfix, thunderbird63 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 63.0
Tracking Flags:
Tracking Status
thunderbird_esr60 --- fixed
thunderbird62 --- wontfix
thunderbird63 --- fixed

People

(Reporter: thomas8, Assigned: thomas8)

References

Details

Attachments

(1 file, 1 obsolete file)

1477816_reorderAttachmentsKey.patch
2.43 KB, patch
jorgk-bmo
: review+
jorgk-bmo
: approval-comm-esr60+
Details | Diff | Splinter Review
+++ This bug was initially created as a clone of Bug #1475828 +++ This bug suggests to change/normalize Alt+X (Ctrl+X on Mac) into a regular keyboard shortcut, Ctrl+Shift+X (Cmd+Shift+X on Mac), which appears to be available in TB (1), and also on MAC (2). (1) http://mzl.la/1ApHkv8 (2) https://support.apple.com/en-us/HT201236 Background information: Whilst using Alt+X to show the "Reorder attachments" dialog in en-US is highly convenient and there's nothing wrong with it in principle, it's in the range of access keys and unfortunately not all localizers have ensured its uniqueness. A sample failure is German where Alt+X is already taken for "Extras" main menu, so Reorder Attachments Alt+X shortcut fails because it wasn't localized. Maybe localizers didn't want to localize command keys as a matter of principle. This is different from Bug #1475828 because here there's no underlying unique access key which could be extended, although "Reorder Attachments" actually also sets focus on attachment pane so using an access key might have some justification (however, we already have an access key for attachment pane, Alt+M in EN). Given the resistance of some localizers against localizing what they perceive as a different animal (command <keys>), maybe it's more consistent, safer, less error-prone and easier to document if we use a regular shortcut key instead.
access key "x" as an entity in composition: https://dxr.mozilla.org/l10n-central/search?q=regexp%3Aaccesskey.*x+path%3A*%2Fmail%2Fchrome%2Fmessenger%2Fmessengercompose%2Fmessengercompose.dtd&redirect=false access key "x" as a property in composition: -> composeMsgs.properties Shortcut key reorderAttachmentsCmd.key (Alt+X on en-US and many others): https://dxr.mozilla.org/l10n-central/search?q=%22%3C!ENTITY+reorderAttachmentsCmd.key%22&redirect=false
And this few-liner fixes it. Richard?
Attachment #8994324 - Flags: ui-review?(richard.marti)
Attachment #8994324 - Flags: review?(jorgk)
Summary: Eliminate localization errors of "Reorder Attachments" keyboard shortcut key → Eliminate localization errors of "Reorder Attachments" keyboard shortcut key (change Alt+X to Ctrl+Shift+X)
No longer blocks: 1473488
Comment on attachment 8994324 [details] [diff] [review] Patch V.1: Change Alt+X to Ctrl+Shift+X Review of attachment 8994324 [details] [diff] [review]: ----------------------------------------------------------------- ::: mail/locales/en-US/chrome/messenger/messengercompose/messengercompose.dtd @@ +86,5 @@ > <!ENTITY renameAttachmentCmd.label "Rename Attachment…"> > <!ENTITY renameAttachmentCmd.accesskey "e"> > <!ENTITY reorderAttachmentsCmd.label "Reorder Attachments…"> > <!ENTITY reorderAttachmentsCmd.accesskey "s"> > +<!ENTITY reorderAttachmentsCmd2.key "x"> Why change the name?
Actually, for ESR 60 we can't do new strings.
We have to change the name because some localizations have already done the right thing under our wrong dispensation, namely they localized this shortcut key. But now we're going for one-for-all, meaning international, normally non-localized shortcut key. If we kept the old ID, we'd get it all wrong with national flavors of an international shortcut key, and with unpredictable results because we're changing the modifiers. (In reply to Jorg K (GMT+2) from comment #4) > Actually, for ESR 60 we can't do new strings. This isn't a new string which anyone needs to translate; in fact, translation is unwanted unless required by special circumstances of the locale. It will work without even the slightest problem for most, if not all localizations (more below). Maybe for locales with non-latin keyboards it won't work out of the box, but even if we don't change anything, we still have several failing localizations, so I'd rather go for clean and safe code with a few remote fallouts than error-prone code and non-sustainable shortcut key with several fallouts even in core localizations. Nothing bad happens even if the shortcut doesn't work in Egypt, the feature is still there and fully accessible, and active localizers will fix it in the next round. The untranslated "new" string will work flawlessly for most/all localizations because this is what really happens: I understand the new string automatically gets duplicated into all localized language files. If it's not translated, the en-US template translation remains in the locale (as we recently saw with English strings in the German because their translations hadn't landed yet). That's exactly what we want, namely this shortcut to be the same internationally, perhaps with few exceptions where technically it's not feasable. As a side note, fwiw, I don't believe in the "can't do new strings" mantra - as long as we're not reinventing the wheel and bombarding localizers with dozens of new translations, I'm failing to see why we would ever prefer to keep bugs and wrong/error-prone/confusing UI/UX rather than just asking localizers to tweak one or two strings - if they don't make it in time, it remains an English string, which doesn't look like a big problem. But anyway, not relevant here.
(In reply to Thomas D. (currently busy elsewhere) from comment #5) > We have to change the name because some localizations have already done the > right thing under our wrong dispensation, namely they localized this > shortcut key. No. https://dxr.mozilla.org/l10n-central/search?q=reorderAttachmentsCmd.key&redirect=false We can't have a new string or hell will break loose.
OK, I was wrong, very few got localised: fi, el, he. But let's not mess with it.
Comment on attachment 8994324 [details] [diff] [review] Patch V.1: Change Alt+X to Ctrl+Shift+X As discussed on IRC, I prefer not to introduce a new string here. In general, all these changes are months too late. You should have checked it on the first beta that contained the function. Betas are available in all languages and back then we would have had plenty of time to get it right. Slipping such changes into an ESR two days before the final build is really, well, hos shall I say it, not the most prudent thing to do :-(
Attachment #8994324 - Flags: review?(jorgk)
Comment on attachment 8994324 [details] [diff] [review] Patch V.1: Change Alt+X to Ctrl+Shift+X Removing the ui-r until it's clear what name should be used.
Attachment #8994324 - Flags: ui-review?(richard.marti)
This would be the patch to try. The "Polish" patch from bug 1475828 needs to be applied first. Thomas, reading the commit message I see Ctrl+Shift+X/Cmd+Shift+X and the chosen modifier is "accel,shift". So "accel" is the Apple key on Mac. Why don't we use "control" on Mac as well. Once we've landed those patches, I'll post this to the l10n mailing list: --------------------- Dear l10n contributor and friend of Thunderbird, we have recently discussed the access/command key localisation for the new attachment functionality in Thunderbird 60. We made some adjustments, can can you please try out our new build Thunderbird 60 ESR build 3 available from https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/build3/. We made the following adjustments. The attachment pane, when shown, has a header and this header has an access key, attachments.accesskey, on Windows and Linux, Alt+M in English. We are now also using this key as command key on the "View" menu to display the pane when not visible. In German what would be Alt+N and in Finnish Alt+E. The reason for doing so is that using an Alt key in the first place was an unfortunate design decision since it conflicts with other access keys. For example Alt+M is used in German for the attachment reminder. On Windows and Linux using the pane's access key should work in all locales since this key must be available since it accesses the pane when shown. We recognise the conflation of access key and command key in this special case. On Mac, which has no access keys, we use toggleAttachmentPaneCmd.key, but we changed the modifier to "control". Again, this is not really a change since Mac users already had to press Ctrl to access the functionality. We noticed that Polish is using "a" in toggleAttachmentPaneCmd.key, so that conflicts with Mac's Ctrl+A [delete this sentence depending on what we find in bug 1475828]. We changed the modifier of the key to launch the "reorder attachment" panel (reorderAttachmentsCmd.key) from Alt+X to Ctrl+Shift+X in English. This was done since again the Alt modifier conflicted with others, for example in German Alt+X was for the tool menu (Extra). Please check you locale to make sure Ctrl+Shift+<your localised key> is working. Please accept our apologies for the excessively late changes. Only as localised builds of Thunderbird 60 have become available were we able to detect these problems. Most locales should not be affected at all. We haven't made these changes without a lot of (very late night) deliberation. This is the best we could do to ensure that the new functionality works as it should. Thanks for your cooperation.
Richard, not to waste any time here, can you please try modifiers="accel,shift" and also modifiers="control,shift". Based on the results, we can decide.
modifiers="accel,shift" is command+shift+x and modifiers="control,shift" control+shift+x. And both are working from everywhere focused in the compose window.
Attachment #8994324 - Attachment is obsolete: true
So we're done here as soon as Thomas explains why he submitted a patch to use accel=command on Mac. Richard (as per IRC conversation) and I both prefer control.
Regarding the text in comment #10: Yes, we need to include this: We noticed that Polish is using "a" in toggleAttachmentPaneCmd.key, so that conflicts with Mac's Ctrl+A. Also, this is incorrect: On Mac, which has no access keys, we use toggleAttachmentPaneCmd.key, but we changed the modifier to "control". Nothing was changed, see: https://hg.mozilla.org/comm-central/rev/28c699e91513#l2.11 It *was* always control. So nothing has changed at all. The only change is that we force the key on Windows now which makes good sense.
(In reply to Jorg K (GMT+2) from comment #10) > Created attachment 8994429 [details] [diff] [review] > 1477816_reorderAttachmentsKey.patch > > This would be the patch to try. The "Polish" patch from bug 1475828 needs to > be applied first. > > Thomas, reading the commit message I see Ctrl+Shift+X/Cmd+Shift+X and the > chosen modifier is "accel,shift". So "accel" is the Apple key on Mac. Why > don't we use "control" on Mac as well. No, we want to make it a proper, regular keyboard shorcut. The regular modifier for keyboard shortcuts is "accel" (accelerator), which is Ctrl on Win/Linux, and Command on Mac. We also want keyboard shortcuts to be as consistent as possible between windows and MAC. on Win, we can't use Ctrl+X (cut to clipboard), so there's no reason to use Ctrl+X on Mac and create unnecessary inconsistencies and use a non-default accelerator (Ctrl) on mac. That's also error-prone because it will certainly be tried for clipboard. > Once we've landed those patches, I'll post this to the l10n mailing list: > > --------------------- > > Dear l10n contributor and friend of Thunderbird, > > we have recently discussed the access/command key localisation for the new > attachment functionality in Thunderbird 60. We made some adjustments, can > can you please try out our new build Thunderbird 60 ESR build 3 available > from > https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/ > build3/. > Suggestion to replace the following two paragraphs with my proposal below. > We made the following adjustments. The attachment pane, when shown, has a > header and this header has an access key, attachments.accesskey, on Windows > and Linux, Alt+M in English. We are now also using this key as command key > on the "View" menu to display the pane when not visible. In German what > would be Alt+N and in Finnish Alt+E. The reason for doing so is that using > an Alt key in the first place was an unfortunate design decision since it > conflicts with other access keys. No, this isn't right, no unfortunate design in the first place, only deviant localizations. This makes it sound as if our decision to use access key at all is still "unfortunate design", which it isn't, it's deliberate and useful. > For example Alt+M is used in German for > the attachment reminder. On Windows and Linux using the pane's access key > should work in all locales since this key must be available since it > accesses the pane when shown. We recognise the conflation of access key and > command key in this special case. I think the first two paragraphs should be rephrased to more positively present the concept of just extending the existing local access key to do more, which is highly convenient and mnemonic, and also resource-efficient as we're not using new key combos which are in short supply. Rephrasing proposal: On Windows/Linux, every locale already has a pre-existing, unique, localized access key for the attachment pane, the underlined character in the "N attachments" header label. Users are already familiar with this key combo to focus the attachment pane when it is shown (which requires this local access key to be unique). For users' convenience, the localized access key of the attachment pane (e.g. Alt+M for English) now also works to show the bucket when it's hidden, and to hide the bucket when it's shown and focused. So with a single known key combo, users can now access and toggle the attachment pane, which is easy to use and to remember (high mnemonic value). Iow, users can now conveniently use the extended access key to do more. > On Mac, which has no access keys, we use toggleAttachmentPaneCmd.key, but we > changed the modifier to "control". Again, this is not really a change since > Mac users already had to press Ctrl to access the functionality. We noticed > that Polish is using "a" in toggleAttachmentPaneCmd.key, so that conflicts > with Mac's Ctrl+A. Wrong: we have NOT changed the modifier, we have made the command key "international rather than local. Rephrase previous paragraph: As Mac does not have localized access keys, we are now using Ctrl+M as an *international* key combo, where the "M" is internally realized as toggleAttachmentPaneCmd.key, which only applies to MAC. This means that you should not localize toggleAttachmentPaneCmd.key "m" unless there are specific reasons in your locale to do so, e.g. when "m" is not available on your locale's keyboard layout or such. For many locales, there's no change as they already have "m". We can't localize the Mac key combo because it's likely to interfere with Mac system-wide keyboard shortcuts. E.g., we noticed that Polish currently has toggleAttachmentPaneCmd.key "a", which conflicts with Mac's Ctrl+A for moving to the beginning of the line or paragraph. > We changed the modifier of the key to launch the "reorder attachment" panel > (reorderAttachmentsCmd.key) from Alt+X to Ctrl+Shift+X in English. This was > done since again the Alt modifier conflicted with others, for example in > German Alt+X was for the tool menu (Extra). Please check you locale to make > sure Ctrl+Shift+<your localised key> is working. No, no, no!!! This is NOT a localized key, it must remain "X" for all locales whereever possible. That's the whole point of making it a proper shortcut key, as opposed to hijacking an access key which conflicts with other local access keys. Shortcut keys are international under our control hence in theory can never conflict. Rephrase previous paragraph: For similar reasons, we have changed the modifier of the key combo to show the "Reorder Attachments" panel from localized Alt+X to non-localized/international keyboard shortcut Ctrl+Shift+X (Cmd+Shift+X on Mac). This was necessary since again the key combo with Alt modifier conflicted with other localized access keys, for example in German Alt+X was for already taken for the tools menu (E_x_tras). Please double-check your locale to make sure that Ctrl+Shift+X works to show the "Reorder Attachments" panel. > Please accept our apologies for the excessively late changes. Only as > localised builds of Thunderbird 60 have become available were we able to > detect these problems. Most locales should not be affected at all. We > haven't made these changes without a lot of (very late night) deliberation. > This is the best we could do to ensure that the new functionality works as > it should. > > Thanks a lot for your cooperation, which is much appreciated.
I changed the last line to sound more friendly: Thanks a lot for your cooperation, which is much appreciated.
As for notation in code, modifier="accel" (= Ctrl on Win/Linux, Cmd on Mac) is the preferred syntax because it it's cross-OS hence eliminates the need for branching in code for Mac vs. Windows, and that's what we use everywhere.
Comment on attachment 8994429 [details] [diff] [review] 1477816_reorderAttachmentsKey.patch OK. Can you refresh my memory, why did we go for Ctrl+M in the other bug on Mac and not Command+M? Here you're making the case for Command. Can you give me the entire l10n text, so I don't have to piece it together. Hold on, I have a better idea, *you* post to that group ;-) - That will keep me out of strive :-)
Attachment #8994429 - Flags: review+
OK, Command-M is miminise.
(In reply to Jorg K (GMT+2) from comment #18) > Comment on attachment 8994429 [details] [diff] [review] > 1477816_reorderAttachmentsKey.patch > > OK. Can you refresh my memory, why did we go for Ctrl+M in the other bug on > Mac and not Command+M? Here you're making the case for Command. > > Can you give me the entire l10n text, so I don't have to piece it together. > Hold on, I have a better idea, *you* post to that group ;-) - That will keep > me out of strive :-) Smart move... ;-> will do this evening
Please only post there when TB 60 ESR build 3 is available from https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/build3/. This will land tonight and Wayne will do the build on Wednesday.
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/6181f7c5393b Change "Reorder Attachments" shortcut to Ctrl+Shift+X/Cmd+Shift+X. r=jorgk, ui-r=Paenglab
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 63.0
Attachment #8994429 - Flags: approval-comm-esr60+
Attachment #8994429 - Flags: approval-comm-beta+
(In reply to Jorg K (GMT+2) from comment #18) > Comment on attachment 8994429 [details] [diff] [review] > Can you give me the entire l10n text, so I don't have to piece it together. Dear l10n contributor and friend of Thunderbird, we have recently discussed the access/command key localisation for the new attachment functionality in Thunderbird 60. We realized that our implementation was irritating some localizers, resulting in wrong and broken localizations. So we have made some adjustments to eliminate these problems, but as we can't ship new strings at this point, we still need a little bit of help from you to verify and in some cases correct your localization. Can can you please try out our new build Thunderbird 60 ESR build 3, available from: https://archive.mozilla.org/pub/thunderbird/candidates/60.0-candidates/build3/ On Windows/Linux, every locale already has a pre-existing, unique, localized access key for the attachment pane, the underlined character in the "N attachments" header label. Users are already familiar with this key combo to focus the attachment pane when it is shown (which requires this local access key to be unique). For users' convenience, the localized access key of the attachment pane (e.g. Alt+M for English, or Alt+N for German) now also works to show the bucket when it's hidden, and to hide the bucket when it's shown and focused. So with a single known key combo, users can now access and toggle the attachment pane, which is easy to use and easy to remember (high mnemonic value). Iow, users can now conveniently use the extended access key to do more. This feature now works out of the box without requiring further localization. As Mac does not have localized access keys, we are now using Ctrl+M as an *international* key combo to access the attachment pane, where the "M" is internally realized as toggleAttachmentPaneCmd.key, which only applies to MAC. This means that you should not localize toggleAttachmentPaneCmd.key "m" unless there are specific reasons in your locale to do so, e.g. when "m" is not available on your locale's keyboard layout or such. For many locales, there's no change as they already have "m". We can't localize the Mac key combo because it's likely to interfere with Mac system-wide keyboard shortcuts. E.g., we noticed that Polish currently has toggleAttachmentPaneCmd.key "a", which conflicts with Mac's Ctrl+A for moving to the beginning of the line or paragraph. Please verify that your localization has toggleAttachmentPaneCmd.key "m". For similar reasons, and in accordance with your feedback, we have changed the modifier of the key combo to show the "Reorder Attachments" panel from localized Alt+X to non-localized/international keyboard shortcut Ctrl+Shift+X (Cmd+Shift+X on Mac). This was necessary since again the key combo with Alt modifier conflicted with other localized access keys, for example in German Alt+X was for already taken for the tools menu (E_x_tras). Please double-check your locale to make sure that Ctrl+Shift+X works to show the "Reorder Attachments" panel. Please accept our apologies for the excessively late changes. Only as localised builds of Thunderbird 60 have become available were we able to detect these problems. Most locales should not be affected at all. We haven't made these changes without a lot of (very late night) deliberation. This is the best we could do to ensure that the new functionality works as it should. Thanks a lot for your cooperation, which is much appreciated.
Great, you send it, right? Can you make these amendments: ... localized access key for the attachment pane, *attachments.accesskey*, ... ... key combo to show the "Reorder Attachments" panel, *reorderAttachmentsCmd.key*, ... I want to name the strings explicitly so people can look them up and try them out. Would you also like to give me the blurb for the release notes? Uplifts are done, Wayne will build within the next 24 hours, build should be available in the next 48 hours.
Attachment #8994429 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: