New attachment pane functionality in Thunderbird 60, currently (still) in beta, keys incorrectly translated

[Jorg Knobloch]

Hi all,

it has come to my attention that the access keys for the new attachment pane functionality have been incorrectly translated in some/most locales.

There are three access keys that should all be the same:

attachments.accesskey
toggleAttachmentPaneCmd.accesskey
toggleAttachmentPaneCmd.key

attachments.accesskey is the access key on the attachment pane header.

toggleAttachmentPaneCmd.accesskey is the access key on the View menu of a Compose/Write window.

toggleAttachmentPaneCmd.key is a keyboard shortcut, not an access key, which will show or hide the attachment pane.

Picture here:
http://www.jorgk.com/misc/attachments.png

If these keys are not translated properly, some functionality in TB will not work :-(

Jörg.

[Francesco Lodolo [:flod]]

Il 06/07/18 10:42, Jorg Knobloch ha scritto:

I'm not surprised most locales got it wrong (I would have too…). It
looks like this UI is mixing up access keys and shortcuts? Is that
really the case?

Why should accesskey and shortcut use the same letter? There's no
guarantee that all languages will have a M in the label.

Francesco

[Jorg Knobloch]

On Friday, July 6, 2018 at 10:51:28 AM UTC+2, Francesco Lodolo [:flod] wrote:
> I'm not surprised most locales got it wrong (I would have too…). It
> looks like this UI is mixing up access keys and shortcuts? Is that
> really the case?
>
> Why should accesskey and shortcut use the same letter? There's no
> guarantee that all languages will have a M in the label.

I hope the author of the patches can answer that.

We've just landed a patch to make TB work when the shortcut command key (toggleAttachmentPaneCmd.key) is different:
https://bugzilla.mozilla.org/show_bug.cgi?id=1473488

However, I think some locales still need to fix their shortcut command keys, for example German has toggleAttachmentPaneCmd.key "m", where "m" doesn't appear at all in "Anhang" or "Anhänge" (German for attachment(s)). So not a very good mnemonic.

[Francesco Lodolo [:flod]]

Il 06/07/18 11:04, Jorg Knobloch ha scritto:

> However, I think some locales still need to fix their shortcut command keys, for example German has toggleAttachmentPaneCmd.key "m", where "m" doesn't appear at all in "Anhang" or "Anhänge" (German for attachment(s)). So not a very good mnemonic.

Shortcuts are not localized normally. As a user, you would expect CTRL+T
to open a new tab, independently from the language, CTRL+W to close a
window, etc. So, in this case I would expect CTRL+M to remain CTRL+M in
German, and the accesskey to be adapted to the label.

Francesco

[Jorg Knobloch]

On Friday, July 6, 2018 at 11:12:17 AM UTC+2, Francesco Lodolo [:flod] wrote:
> Shortcuts are not localized normally. As a user, you would expect CTRL+T
> to open a new tab, independently from the language, CTRL+W to close a
> window, etc. So, in this case I would expect CTRL+M to remain CTRL+M in
> German, and the accesskey to be adapted to the label.

OK. I mostly got all I said wrong :-(

Updated picture here: http://www.jorgk.com/misc/attachments.png

Yes, in the said bug we made TB work when the shortcut command key is different to the access key(s).

Just ignore me.

Jörg.

[Jorg Knobloch]

There's still something work in the German localisation. The German string doesn't show: https://bug1473488.bmoattachments.org/attachment.cgi?id=8990239.
Seen in TB 60 beta 9.

It was translated here:
https://hg.mozilla.org/l10n-central/de/rev/19c5811f5e3d#l9.12

[Francesco Lodolo [:flod]]

Il 06/07/18 11:28, Jorg Knobloch ha scritto:

I confess I don't fully understand Thunderbird's release cycle at this
point, but the latest sign-off for German is from May 1st (one changeset
before the one you linked)
https://hg.mozilla.org/l10n-central/de/pushloghtml?changeset=2c1a3f49405e

That string was committed 2 days later.

Francesco

[thomasd....@gmail.com]

Ok, here's the story:

Access keys are in short supply - German has a number of broken access keys (see http://bugzil.la/1469835) shared between more than one element on same level, which is illegal.
Shortcut keys are also in short supply - e.g., Ctrl+M is already taken for "New Message" so you can't use that for attachment pane. Function keys (like F9 for contacts side bar) are not very mnemonic; Ctrl+Shift+M seems to be available, we could consider that if we really want an international shortcut key for this, but again it's not very mnemonic. But: is it really worth investing a dedicated international shortcut key when the localized access key can do the job? I mean, how often do people use Thunderbird in another language? Even in another language, you could still just use their advertised access key for the full magic.

So here's the intended design:

For user's convenience, and to avoid wasting another shortcut key, we want to re-use the access key as a shortcut key for hiding and showing the attachment pane. I.e. technically, access key and shortcut key should be the same, as Jörg has explained above. This is highly convenient, ux-efficient and has excellent mnemonic value because users only have to remember a single (localized) key combo to access and toggle the attachment pane; moreover, that key combo is very visible as an access key on the "N attachments" label (and also advertised on the View Menu).

Iow, the following functions conveniently share the same key combo (e.g. Alt+M for en-US, or Alt+N for de-DE):
- Show and focus attachment pane (when empty and hidden, or full and minimized)
- Focus attachment pane (when it's visible but doesn't have focus - classic access key)
- Hide attachment pane (when it's visible and has focus)
This may sound weird in theory, but it's actually very simple in practice: Just press Alt+M (or whatever your localized access key) one time or maximally two times, and you'll show+focus or hide the attachment pane as you wish, as the same shortcut will conveniently cycle between the view states, and also ensure useful focus at any time.

That said, everything will still work correctly even for deviant localizations like German who define different character for access key (e.g. M) vs. shortcut key (e.g. N). Only it will be less convenient and less mnemonic, and you'll waste another access key, which is likely to cause problems, as it currently does for German.

[Jorg Knobloch]

On Friday, July 6, 2018 at 2:12:01 PM UTC+2, thomasd....@gmail.com wrote:
> That said, everything will still work correctly even for deviant
> localizations like German who define different character for
> access key (e.g. M) vs. shortcut key (e.g. N). Only it will be
> less convenient and less mnemonic, and you'll waste another
> access key, which is likely to cause problems, as it currently
> does for German.

Easy to get confused here ;-( - I think German has "N" as the access key, as in "A(n)hang", and left the English command shortcut key "M".

[Onno Ekker]

On Fri, Jul 6, 2018 at 2:12 PM, <thomasd....@gmail.com> wrote:

> Access keys are in short supply - German has a number of broken access
> keys (see http://bugzil.la/1469835) shared between more than one element
> on same level, which is illegal.
>

Double access keys aren't illegal, only inconvenient. The normal way, when
an access key is unique to a menu, you will directly choose the menuitem by
pressing the access key. If the access key isn't unique, pressing the
access key only selects the first menuitem and pressing the access key
again switches to the next menuitem with that access key and when there are
no more menuitems it switches back to the first. In order to choose the
menuitem, you have to press Enter. This behavior is demonstrated in
Thunderbird 60 for the Tools menu, where both Add-on Options and Options
have access key O. So if possible, double access keys should be avoided,
but they are not illegal.

Command keys or shortcut keys have to be unique though. When you press a
command key combination, it immediately executes the command. There is no
way to first select one of the commands and then execute it. So if a
command key is used twice in a screen, it doesn't work. That's one of the
reasons that command keys shouldn't be localized (that is, if the key is
available on the keyboard for that locale).
Onno

[thomasd....@gmail.com]

Am Freitag, 6. Juli 2018 16:44:30 UTC+2 schrieb Onno Ekker:

> On Fri, Jul 6, 2018 at 2:12 PM, Thomas D. wrote:
>
> > Access keys are in short supply - German has a number of broken access
> > keys (see http://bugzil.la/1469835) shared between more than one element
> > on same level, which is illegal.
> >
>
> Double access keys aren't illegal, only inconvenient.

Well, that depends. You are right that there is no problem about duplicate access keys within a submenu. However... (see below)

> Command keys or shortcut keys have to be unique though. When you press a
> command key combination, it immediately executes the command. There is no
> way to first select one of the commands and then execute it. So if a
> command key is used twice in a screen, it doesn't work.

Indeed. And the same applies to main menu access keys, and to any access keys to focus or trigger elements in the primary (non-menu) UI: They must be unique. Even if it would work to share the same access key between two non-menu UI elements, it would defeat the purpose as it would be very hard to figure out where focus has jumped to. Please read bug http://bugzil.la/1469835 where clearly duplicate access keys are breaking the main menu, except for the workaround of pressing and releasing Alt first to focus the main menu, which seems non-standard according to official Microsoft documentation cited in the bug.

> That's one of the reasons that command keys shouldn't be localized
> (that is, if the key is available on the keyboard for that locale).

Generally right, but not applicable to our issue here.
Attachment pane access key MUST be unique among the locale's access keys, so there is no reason why it couldn't also act as a shortcut key.

[Michal Stanke]

Dne 6.7.2018 v 14:12 thomasd....@gmail.com napsal(a):

> But: is it really worth investing a dedicated international shortcut key when the localized access key can do the job? I mean, how often do people use Thunderbird in another language? Even in another language, you could still just use their advertised access key for the full magic.

I have to disagree with you here. Even if you do not use TB in multiple
languages, you may welcome shortcut keys to be same across languages in
these scenarios:

* You are a user of e.g. Czech TB seeking for help, and you find an
article in English mentioning the shortcut that works in English. Or
a power user with TB in English advises you the shortcut. It would
be very frustrating for you, if the shortcut does not work in Czech
TB, or worse, if it does something completely different.
* You are SUMO localizer and during translating the articles, you may
not want or be able to test all scenarios or verify all shortcuts
works in your localized TB the same. SUMO localizers do not even
have to be familiar with how the product localization work, or even
that the shortcuts are localizable.

> Attachment pane access key MUST be unique among the locale's access keys, so there is no reason why it couldn't also act as a shortcut key.

As for "investing a dedicated shortcut", is there are problem in the
code to write it so, that localizers can decide, if they need to choose
a different key, like we do for any other place in the product? I don't
think mixing command/shortcut keys and accesskey are a good idea.
Despite in the particular case they might behave the same, semantically
they are not the same. And you cannot pretend any short or long term
future, where some refactor will change the situation.

Michal

[thomasd....@gmail.com]

Am Samstag, 7. Juli 2018 13:34:11 UTC+2 schrieb Michal Stanke:

Thanks Michal for your feedback!

> Dne 6.7.2018 v 14:12 thomasd.bugzilla napsal(a):

> > But: is it really worth investing a dedicated international shortcut key when the localized access key can do the job? I mean, how often do people use Thunderbird in another language? Even in another language, you could still just use their advertised access key for the full magic.
> I have to disagree with you here. Even if you do not use TB in multiple
> languages, you may welcome shortcut keys to be same across languages in
> these scenarios:

Yes, in general, shortcut keys are the same internationally and we are not changing that. This is an exception which suggests itself because every locale already has a dedicated access key for attachment pane, so it's actually highly convenient, efficient, mnemonic AND saving a shortcut key to just re-use the access key for toggling the pane. Overloading the access key can never be a problem for any language, because the access key must be unique otherwise it wouldn't work as an access key. Localizers can pick any access key which matches their translation of "N attachments", and TB will automatically accept the same access key for hiding the pane when it is already focused, and showing the pane when it is hidden. So this works reliably and there's no reason to remove this convenient feature.

That said, if there's a general consensus that we want to invest an alternative international shortcut key for toggling the attachment pane (which is not required because the local access key already does all the tricks), we can do that *in addition* to the extended access key functionality.

> * You are a user of e.g. Czech TB seeking for help, and you find an
> article in English mentioning the shortcut that works in English. Or
> a power user with TB in English advises you the shortcut. It would
> be very frustrating for you, if the shortcut does not work in Czech
> TB, or worse, if it does something completely different.

I hear you... Yet both the English article and the power user should correctly point out that this shortcut is your local access key as advertised on the "N attachments" label.

> * You are SUMO localizer and during translating the articles, you may
> not want or be able to test all scenarios or verify all shortcuts
> works in your localized TB the same. SUMO localizers do not even
> have to be familiar with how the product localization work, or even
> that the shortcuts are localizable.

Dito, the original article must point out that this shortcut is same as local access key.

> > Attachment pane access key MUST be unique among the locale's access keys, so there is no reason why it couldn't also act as a shortcut key.
>
> As for "investing a dedicated shortcut", is there are problem in the
> code to write it so, that localizers can decide, if they need to choose
> a different key, like we do for any other place in the product?

That's already possible: Localizers can freely choose an access key for the "N attachments" label, and they can also tweak the corresponding keyboard shortcut. The current recommendation is to make the keyboard shortcut same as access key, but we could agree to have an international keyboard shortcut instead.

> I don't think mixing command/shortcut keys and accesskey are a good idea.

We're not using that as a general recipe, but in this case, extending the functionality of the access key is convenient and it does not prejudice having an alternative international shortcut key in any way.

> Despite in the particular case they might behave the same, semantically

> they are not the same. And you cannot pretend [predict?] any short or long

> term future, where some refactor will change the situation.

Hmmm, that's not quite true. The local access key for "N attachments" label must always be unique to work, so no refactor can change that. There's an explicit comment in the localization files that in the current dispensation, access key and shortcut key should be the same. Fortunately, both access key and shortcut key will still work even if different, unless if localizers specify a shortcut key which is already in use (e.g. as an access key of something else). Iow, localizations which follow the localization instructions can never have a problem. But you right, it's a bit delicate to maintain, as the current confusion shows.

What you are really asking for is to invest an international shortcut key, so please suggest one. International shortcut keys are usually derived from the English locale, but all mnemonic shortcut keys are already taken. Contacts side bar has F9. F10 is taken for activating menu on Windows. F11 seems to be free, maybe we could use that. Yes, that's a bit easier for international documentation, but personally I would much prefer to use my local access key rather than having to remember a random international shortcut key. Ymmv.

[thomasd....@gmail.com]

Btw, please consider that any additional international shortcut key reduces the number of shortcut keys available to both Thunderbird (for future use) AND addons, who need to rely on shortcut keys not already taken by TB.

[thomasd....@gmail.com]

For the sake of completeness:

We could probably reduce the cognitive burden and potential localization errors of the current dispensation by removing the keyboard shortcut <key id="..."> altogether and adding a bit of code to advertise the local access key on the View > Attachment Pane menuitem, and to recreate the <key> from the accesskey for Mac OS, which doesn't use access keys.

[Jorg Knobloch]

Coming back to an earlier post:

On Friday, July 6, 2018 at 11:12:17 AM UTC+2, Francesco Lodolo [:flod] wrote:
> Shortcuts are not localized normally. As a user, you would expect CTRL+T
> to open a new tab, independently from the language, CTRL+W to close a
> window, etc. So, in this case I would expect CTRL+M to remain CTRL+M in
> German, and the accesskey to be adapted to the label.

Other software localises shortcuts. Best examples: Windows and LibreOffice. I know since I maintain both English and Spanish installations.

Windows and LibreOffice:
English: Ctrl+A = Select All
Spanish: Ctrl+E = Select All

LibreOffice:
English: Ctrl+S = Save
Spanish: Ctrl+S = Underline (Subrayar)
Spanish: Ctrl+G = Save (Guardar).

It's painful for people working in different languages, but it's a fact.

[thomasd....@gmail.com]

Am Freitag, 6. Juli 2018 10:51:28 UTC+2 schrieb Francesco Lodolo [:flod]:
> Il 06/07/18 10:42, Jorg Knobloch ha scritto:
> > Hi all,
> >
> > it has come to my attention that the access keys for the new attachment pane functionality have been incorrectly translated in some/most locales.
> >
> > There are three access keys that should all be the same:
> >
> > attachments.accesskey
> > toggleAttachmentPaneCmd.accesskey
> > toggleAttachmentPaneCmd.key
> >
> > attachments.accesskey is the access key on the attachment pane header.
> >
> > toggleAttachmentPaneCmd.accesskey is the access key on the View menu of a Compose/Write window.
> >
> > toggleAttachmentPaneCmd.key is a keyboard shortcut, not an access key, which will show or hide the attachment pane.
> >
> > Picture here:
> > http://www.jorgk.com/misc/attachments.png

> I'm not surprised most locales got it wrong (I would have too…). It
> looks like this UI is mixing up access keys and shortcuts? Is that
> really the case?

There's no mixup. They are defined independently, they work independently, and they are advertised independently.
We have just extended the access key functionality to /also/ act as a shortcut for toggling the attachment pane (hide when it has focus, or show). Extended access key functionality has been coded to work automatically, regardless of the shortcut key. But we are recommending to make access key and shortcut key the same, which has several advantages:

- convenient and efficient
- improved mnemonics: just one key combo to remember for getting in or out of attachment pane
- better ux-discovery of the extended access key, because the shortcut key (== access key for conforming locales) will be advertised on the View > Attachment Pane menuitem.
- avoiding separate shortcut key for toggling, as shortcut keys are in short supply

To simplify things for localizers, we could create the keytext in code so that we eliminate the <key> altogother, as I explained above.

> Why should accesskey and shortcut use the same letter? There's no
> guarantee that all languages will have a M in the label.

No, there's a misunderstanding here.
Every locale already has their localized attachments.accesskey as an existing, unique access key for the "N attachment(s)" label (if it's not unique, it's broken, i.e. someone got it wrong). Then you just assign the same key (e.g. "M" for English, or "N" for German) for toggleAttachmentPaneCmd.key. Iow, you make the shortcut key the same as the localized access key. So that definitely works regardless of your language. Guaranteed.
Then ideally, you also make toggleAttachmentPaneCmd.accesskey the same key again for the menu access key (but no problem if you don't).

[thomasd....@gmail.com]

Am Freitag, 6. Juli 2018 11:12:17 UTC+2 schrieb Francesco Lodolo [:flod]:
> Il 06/07/18 11:04, Jorg Knobloch ha scritto:
> > However, I think some locales still need to fix their shortcut command keys, for example German has toggleAttachmentPaneCmd.key "m", where "m" doesn't appear at all in "Anhang" or "Anhänge" (German for attachment(s)). So not a very good mnemonic.

The bigger problem in German is that Alt+M is already taken for "Mich später erinnern" (Remind me later) on attachment reminder info bar. I.e. whenever the bar is shown, Alt+M does NOT work as a shortcut key to toggle attachment pane.

> Shortcuts are not localized normally. As a user, you would expect CTRL+T
> to open a new tab, independently from the language, CTRL+W to close a
> window, etc. So, in this case I would expect CTRL+M to remain CTRL+M in
> German, and the accesskey to be adapted to the label.

First of all, Ctrl+M is already taken for "Write".

Then, just to be clear, toggleAttachmentPaneCmd.key has |modifier="alt"| on Windows (and |modifier="control"| on Mac OS). So the resulting shortcut is ALT+* on Windows, where * should be the same as your localized attachments.accesskey.
In the current design (from user's pov), as a net result, there is NO dedicated keyboard shortcut for toggling attachment pane, but ONLY your localized attachments.accesskey with extended functionality (e.g. Alt+M for English, Alt+N for German). We only have <key key="&toggleAttachmentPaneCmd.key;"> as a technicality, which could be eliminated to make things easier for localizers.

I hear where you are coming from, but Jörg is 100% right, in many well-known other applications out there, keyboard shortcuts ARE localized.
Microsoft Office is another example:

English:
Ctrl+B = bold
Ctrl+I = italics
Ctrl+U = underline

German:
Ctrl+Shift+F = bold (Fett)
Ctrl+Shift+K = italics (Kursiv)
Ctrl+Shift+U = underline (Unterstreichen)

For a number of other shortcuts, German is just lucky to have words starting with the same letter as the English word, but I bet other languages are less lucky.

[Ricardo Palomares Martí­nez]

El 08/07/18 a las 12:06, Jorg Knobloch escribió:

> Coming back to an earlier post:
>
> On Friday, July 6, 2018 at 11:12:17 AM UTC+2, Francesco Lodolo [:flod] wrote:
>> Shortcuts are not localized normally. As a user, you would expect CTRL+T
>> to open a new tab, independently from the language, CTRL+W to close a
>> window, etc. So, in this case I would expect CTRL+M to remain CTRL+M in
>> German, and the accesskey to be adapted to the label.
>
> Other software localises shortcuts. Best examples: Windows and LibreOffice. I know since I maintain both English and Spanish installations.
>

> (...)

> It's painful for people working in different languages, but it's a fact.

^^^^^^^^^^^^

It's painful not only for people working in different languages.
[Ctrl]+[S] is Save in almost any Windows application, *except* Windows
accesories, Microsoft Office and LibreOffice, so when you want to save
your document, you instead activates underlining in Spanish
("Subrayado"). And just because of that, localizing shortcuts
shouldn't be done at all, except if the target language uses a
different alphabet.

The "localized" shortcut in Thunderbird is a really bad idea, and
should be undone. Making exceptions to a general rule just because it
seems cool for someone in a very specific scenario, and arguable for
many more people, should be enough for that someone to reevaluate if
that was really as cool as it seemed at first glance.

For the sake of it, es-ES has never localized shortcuts in Mozilla and
it will continue to be that way, at least for the products I localize
(Thunderbird, including Calendar, and SeaMonkey).

--
Proyecto NAVE (Mozilla es-ES Localization Team)
Mozilla Hispano Community

[Jordi Serratosa]

I totally agree with Ricardo.

salut,
jordi s

El dc., 11 de jul. 2018, 00:25, Ricardo Palomares Martí­nez <
rpm....@proyectonave.es> va escriure:

> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
>