1707434 - Add ellipsis (…) to 'File > Save As > File' menu label

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[Nick Levinson]

STR:

1. Select a set of emails. It may have to be a localhost collection of emails.
2. Go to Inbox or Sent.
3. Select an email or multiple emails.
4. Go to File > Save As > File.

Actual result:

The last menu item says "File Ctrl+S". Selecting it takes the user to a dialog.

Tbird version 78.8.1 (64-bit).

Expected result:

The last menu item should say "File... Ctrl+S".

When a menu command is to be followed by a dialog with choices, this is to be announced to the user before the command is selected. See, e.g., https://docs.microsoft.com/en-us/previous-versions/windows/desktop/bb246448(v=vs.85) and https://developer.apple.com/design/human-interface-guidelines/macos/menus/menu-anatomy/ . It reassures the user that no harm will come from just selecting the command. Therefore, the user who is unsure of risking using that command can safely try it out.

Relevant: Bug 328586 and bug 992643.

The ellipsis is a single character in Unicode, not three characters.

Arguably, in English syntax those are suspension points and not an ellipsis, but in programming it's called an ellipsis and maybe it is in English, too.

Comment 1

[Thomas D. (:thomas8)]

Thanks Nick, that's right!

Comment 2

[Liscare]

Attachment: Bug 1707434 - Add ellipsis to Save As > File menu label. r=ThomasD

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4d5a54c9cf68
Add ellipsis to Save As > File menu label. r=ThomasD

Comment 4

[Magnus Melin [:mkmelin]]

Hmm, I think this is an example of incorrect usage of message references. You can't know the accesskey would always fit in with with the surrounding context, and the everybody would have to update both places.
Not to mention, the app-menu doesn't use accesskeys...

https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#message-references

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/d6f9f7136614
followup - remove message-reference. rs=me DONTBUILD

Comment 6

[Thomas D. (:thomas8)]

Attachment: Screenshot: Fluent messages with vs. without message reference

(In reply to Magnus Melin [:mkmelin] from comment #4)

Hmm, I think this is an example of incorrect usage of message references.

As you had mentioned this before, I had carefully checked this for correct usage. The message reference which you have removed was correct imo, following exactly the document which you mentioned [1]:

Message References
[snip]
On the other hand, this approach is helpful if, for example, you want to reference another element of the UI in your message:

help-button = Help
help-explanation = Click the { help-button} to access support

This enforces consistency and, if help-button changes, all other messages will need to be updated anyway.

I think that's exactly what we want here: We want to enforce consistency between the main menu and the app menu strings on menuitems (where applicable), so we are "referencing another element of the UI in our message". The message-referencing cases which should be avoided per documentation are different from our case here.

You can't know the accesskey would always fit in with with the surrounding context, and the everybody would have to update both places.

Hmmm - I'm failing to see any access key problem here:

• The original message in the main menu has an access key, which any localization will choose freely according to their needs.
• In the app menu, we explicitly only reference the main menu message with the menuitem label (sic), not the access key message:

appmenu-save-as-file =
    .label = { menu-file-save-as-file.label }

Not to mention, the app-menu doesn't use accesskeys...

Yes, that's why we are referencing only the label-message, not the access key, so no access key is shown on the appmenu (I've just re-tested that). So imho there was nothing wrong with the original solution here, and it would appear to be superior wrt enforcing consistency.

[1] https://firefox-source-docs.mozilla.org/l10n/fluent/review.html#message-references

Comment 7

[Alessandro Castellani [:aleca]]

Sorry Magnus, I agree with Thomas on this as we want to keep consistency between the menu bar and the app menu, or do you see a scenario in which those labels might differ?

...and the everybody would have to update both places.

Maybe we should add a comment above the menu-file-save-as-file fluent string to highlight the fact that we're referencing it in the appmenu-save-as-file, and if the string change, that fluent ID should be updated as well.

The accesskey is not referenced in the app menu at all so that shouldn't be a problem.

Comment 8

[Thomas D. (:thomas8)]

(In reply to Magnus Melin [:mkmelin] from comment #4)

and the everybody would have to update both places.

In fact, it would seem quite the opposite - if we use message referencing, and decide one day that we want to change the template string (unlikely in this case), for app menu we will reference the new string id in the template, which will probably add the app menu message with the updated reference to each locale. But be that as it may, whenever the template string changes, every locale needs to check both spots, regardless of message referencing or not. When a localization just decides to change their own access key on main menu, there's no need for them to change any message IDs, hence no need to update both spots (that applies even when en-Us changes only their access keys).

Comment 9

[Magnus Melin [:mkmelin]]

(In reply to Alessandro Castellani [:aleca] from comment #7)

Sorry Magnus, I agree with Thomas on this as we want to keep consistency between the menu bar and the app menu, or do you see a scenario in which those labels might differ?

I doubt the would ever be different, but that is not the point. Quoting the link above: "This might seem to reduce the work for localizers, but it actually doesn’t help:"

Maybe we should add a comment above the menu-file-save-as-file fluent string to highlight the fact that we're referencing it in the appmenu-save-as-file, and if the string change, that fluent ID should be updated as well.

It's not just the developer that would need to update. You'd also force each of our 65 locales to re-translate.

The accesskey is not referenced in the app menu at all so that shouldn't be a problem.

But it is. If in the future you need to change the menu-file-save-as-file accesskey to accommodate other items in the menu, then you'd have to update menu-file-save-as-file as a whole to something else -> you'd also have to change the dependency in the app-menu (and by change, I mean times 65, per above): appmenu-save-as-file2 AND menu-file-save-as-file2.

I think that's exactly what we want here: We want to enforce consistency between the main menu and the app menu strings on menuitems (where applicable), so we are "referencing another element of the UI in our message".

I would say this was not about referencing another UI element, it was trying to copy strings from a should-be similar element.