Thomas D. (:thomas8) Reporter
	Description • 6 years ago

For German localization of Thunderbird, several main menu access keys in composition window are not working as they have been re-assigned to other UI elements again. Who is responsible for reviewing this!?

Broken access keys:

Main menu:
- D: Datei (hijacked by A_d_ressbuch)
- B: Bearbeiten (hijacked by Blindkopie - massive danger of unintentionally adding selected recipients as BCC!!! ux-error-prevention, privacy)
- A: Ansicht (hijacked by _A_n)
- X: Extras (hijacked by Anhänge neu ordnen keyboard shortcut Alt+X)

Attachment Pane:
- N: 3 A_n_hänge - fails to focus / toggle attachment pane because keyboard shortcut for cmd_toggleAttachmentPane was wrongly defined as Alt+M instead of Alt+N, contrary to localization comment instructions:
> <!ENTITY toggleAttachmentPaneCmd.key "m">
>
> <!-- LOCALIZATION NOTE (attachments.accesskey) This access key character should
>     be taken from the strings in attachmentCount in composeMsgs.properties,
>     and it must be the same as toggleAttachmentPaneCmd.key, otherwise it won't
>     work, as the shortcut key functionality supersedes the access key. -->
> <!ENTITY attachments.accesskey "n">
The actual access key character doesn't matter, but those two must be the same.

	Thomas D. (:thomas8) Reporter
	Comment 1 • 6 years ago

How to fix this - caveats:

Rule of thumb: Main menu access keys have priority and should match 3 pane and OS standards. So we must change the accesss keys of other UI elements like the To/CC/BCC buttons.

Please also consider other not always visible UI elements like the attachment reminder info bar, which consumes Alt+H and Alt+M when present (also currently breaking Alt+M for attachment pane toggle, but Alt+M was wrong for that anyway).

	Thomas D. (:thomas8) Reporter
	Comment 2 • 6 years ago

Maybe while we are here, can we simplify those button labels? Quotation marks and colons aren't needed, and I would also remove the space between |> >|

>> An
>> Kopie (CC)
>> Blindkopie (BCC)

	Thomas D. (:thomas8) Reporter
	Comment 3 • 6 years ago

Hmmm, maybe I spoke too soon.
Main menu access keys can be made to work but only by pressing and releasing Alt first, then pressing their access key, like Alt - release - D for Datei menu.
Now I'm not sure if pressing Alt+D simultaneously is a way of access that we must offer to match the standards.
But I think it used to work that way since time immemorial...

	Thomas D. (:thomas8) Reporter
	Comment 4 • 6 years ago

(In reply to Thomas D. (currently busy elsewhere) from comment #3)
> Hmmm, maybe I spoke too soon.
> Main menu access keys can be made to work but only by pressing and releasing
> Alt first, then pressing their access key, like Alt - release - D for Datei
> menu.
> Now I'm not sure if pressing Alt+D simultaneously is a way of access that we
> must offer to match the standards.
> But I think it used to work that way since time immemorial...

According to this, we must offer Alt+D (simultaneous) combo as an access key:
https://docs.microsoft.com/en-us/dotnet/framework/winforms/controls/how-to-create-access-keys-for-windows-forms-controls

> With an access key, the user can "click" a button by pressing the ALT key in combination with the predefined access key.

	Alex Ihrig [:Thunderbird_Mail_DE]
	Comment 5 • 6 years ago

(In reply to Thomas D. (currently busy elsewhere) from comment #2)
> Maybe while we are here, can we simplify those button labels? Quotation
> marks and colons aren't needed, and I would also remove the space between |>
> >|
> 
> >> An
> >> Kopie (CC)
> >> Blindkopie (BCC)

Maybe we could remove the '>>' entirely. I don't remember my consideration to add these '>>'. In the original en-US entities they aren't existent.

My suggestion:
- An
- Kopie (CC)
- Blindkopie (BCC)
- Antwort an

	Thomas D. (:thomas8) Reporter
	Comment 6 • 6 years ago

(In reply to AlexIhrig from comment #5)
> (In reply to Thomas D. (currently busy elsewhere) from comment #2)
> > Maybe while we are here, can we simplify those button labels? Quotation
> > marks and colons aren't needed, and I would also remove the space between |>
> > >|
> > 
> > >> An
> > >> Kopie (CC)
> > >> Blindkopie (BCC)
> 
> Maybe we could remove the '>>' entirely. I don't remember my consideration
> to add these '>>'. In the original en-US entities they aren't existent.

Hmmm, but en-US has an action on the button:
"Add to To|CC|BCC"
So with ">>", German was translating the verb "Add to" because the German translation would have been to long and very clumsy:
"Zu 'An' hinzufügen".
UI should be action-oriented, so I think ">>" was actually a pretty good visualization of "Add to". ">>" also matches similar UIs where items from one list get copied into another. So I'd lean towards preserving ">>" and just simplifying the recipient notation on the button.

> My suggestion:
> - An
> - Kopie (CC)
> - Blindkopie (BCC)
> - Antwort an

"Antwort an" is not part of the buttons we are talking about.

	Thomas D. (:thomas8) Reporter
	Comment 7 • 6 years ago

Alex, would you be able to fix the following string asap:

https://dxr.mozilla.org/l10n-central/source/de/mail/chrome/messenger/messengercompose/composeMsgs.properties#194
attachmentBucketAttachFilesTooltip=Datei(en) als Anhang anfügeb

The spelling mistake but also the wording in the tooltip is quite odd, let's polish this before release!
This should become:
attachmentBucketAttachFilesTooltip=Datei(en) als Anhang hinzufügen

"Anhang anfügen" klingt nicht wirklich gut, wohingegen "Anhang hinzufügen" konsistent ist mit anderen Strings...

	Thomas D. (:thomas8) Reporter
	Comment 8 • 6 years ago

(In reply to Thomas D. (currently busy elsewhere) from comment #7)
> Alex, would you be able to fix the following string asap:
> 
> https://dxr.mozilla.org/l10n-central/source/de/mail/chrome/messenger/
> messengercompose/composeMsgs.properties#194
> attachmentBucketAttachFilesTooltip=Datei(en) als Anhang anfügeb
> 
> The spelling mistake but also the wording in the tooltip is quite odd, let's
> polish this before release!
> This should become:
> attachmentBucketAttachFilesTooltip=Datei(en) als Anhang hinzufügen
> 
> "Anhang anfügen" klingt nicht wirklich gut, wohingegen "Anhang hinzufügen"
> konsistent ist mit anderen Strings...

Oh, just realized that "Datei(en) als Anhang anfügen" is also in the attach button's dropdown menu, so we'd also have to change it there to be consistent.

	Alex Ihrig [:Thunderbird_Mail_DE]
	Comment 9 • 6 years ago

The above l10n/need-information request goes to Sebastian.

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 10 • 6 years ago

https://hg.mozilla.org/l10n-central/de/rev/6bf9ab1f04f7 nimmt folgende Änderungen vor:

">> An:" verwendet jetzt "n" als Accesskey.
">> Blindkopie (BCC)" verwendet jetzt "p" als Accesskey.
"Adressbuch:" verwendet jetzt "u".
"Anhang:" verwendet jetzt "m" wie der Commandkey, allerdings wird dadurch der Accesskey extra dargestellt "1 Anhang (M)"

	Jorg K (CEST = GMT+2)
	Comment 11 • 6 years ago

I'm sure Thomas will comment here separately.

I don't think it was necessary to change the access key to "m" causing it to be displayed separately. Leaving "n" as access key and "m" as command key would have been fine, unless you absolutely wanted the somewhat meaningless "m" as command key to match the English version. Since bug 1475828 we actually use the access key as command key automatically in Windows/Linux, see:
https://groups.google.com/d/msg/mozilla.dev.l10n/TUYR0Y4I41I/eExjwM9SAwAJ.

If anything, I would have changed the command key to "n", which of course would have only taken a visible effect on Mac.

	Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)
	Comment 12 • 6 years ago

">> An" has practically only the options "A" and "n" for the accesskeys. "A" is in use for "Ansicht", so it has to use "n" which is not available for "Anhang/Anhänge". "h" is in use for "Hilfe". Only letter left: "g":

https://hg.mozilla.org/l10n-central/de/rev/c611466ccdb6