1729447 - Change "Open containing folder" string to "Show in folder"

Status: RESOLVED FIXED

(Firefox :: Downloads Panel, task, P2)

Description

[Romain Testard [:RT]]

On the download panel, the context menu appearing on the folder icon currently has an entry "Open containing folder".
We discussed with Meridel and decided to have it changed to "Show in folder" in order to align with other browser conventions given the current string feels too clunky as it is currently.

Comment 1

[Romain Testard [:RT]]

See also https://bugzilla.mozilla.org/show_bug.cgi?id=469441#c72 where we'll be using a similar label for consistency

Comment 2

[Marco Bonardo [:mak]]

Apparently a few strings at the end of downloads.properties, included showLabel and showMacLabel are no more used and can be removed as part of this bug.
The other strings are using Fluent: https://searchfox.org/mozilla-central/rev/45e308665eb9fc52fd21e2d4b3b959f3cec13ef1/browser/locales/en-US/browser/downloads.ftl#34,53,59,64 it seems worth to change l10n identifiers by adding a "-2" suffix to them.

I'll set the bug as mentored, if this is a priority please let us know.

Comment 3

[Lebar]

So, are we standardizing on "Show in Folder" across platforms or just for non-Mac? I guess with the other referenced change (469441) it didn't matter since we were referring to bookmark folders within the browser itself. But I suppose that the case could be made to stick with "Show in Folder" for downloads across platforms (including for macOS), since it is general enough (though I see that Chrome still uses "Show in Finder" on Mac).

If keeping "Show in Finder", would the new strings not just use the Fluent approach, replacing the original strings? I'm not sure that I understand what the "-2" suffix would be for. It seems that downloadsPanel.inc.xhtml and downloadsContextMenu.inc.xhtml could just be changed to the new approach... or I'm just missing something.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Lebar from comment #3)

So, are we standardizing on "Show in Folder" across platforms or just for non-Mac?

This is a very good question, in my opinion, when we refer to the OS folders we should keep using Show in Finder on the Mac.
I'll ni? Romain to double check whether I'm right.

If keeping "Show in Finder", would the new strings not just use the Fluent approach, replacing the original strings?

We should keep using Fluent, the -2 suffix is necessary for the translation system, basically if we change a string enough to change its semantics, we must replace the string id, that will notify translators that a string is missing and requires attention. In this case I think it's worth changing the id because these Show in Folder changes should stay in sync across the UI. I suggested to just add a -2 to the id because the current id name is good enough and changing it could be challenging.

Comment 5

[Romain Testard [:RT]]

(In reply to Marco Bonardo [:mak] from comment #4)

(In reply to Lebar from comment #3)

So, are we standardizing on "Show in Folder" across platforms or just for non-Mac?

This is a very good question, in my opinion, when we refer to the OS folders we should keep using Show in Finder on the Mac.
I'll ni? Romain to double check whether I'm right.

I had not realized there was a custom string for macOS there. I agree that retaining "Show in Finder" on mac seems to make sense here. I NI Meridel to check I'm not missing anything.

Comment 6

[Meridel [:meridel]]

We should retain "Show in Finder" as the string for MacOS — this is standard across browsers and also accurate in describing what OS program gets opened.

Comment 7

[fatimaolasunkanmi01]

Marco Bonardo [:mak] kindly assign this task to me

Comment 8

[Lebar]

Attachment: Bug 1729447 - Changed downloads context menu string for non-Mac from "Open Containing Folder" to "Show in Folder" to align terminology. r=mak

Comment 9

[Lebar]

Sorry @fatimaolasunkanmi01 - I didn't check this comment thread before uploading a patch. I must have just missed it. Perhaps I can abandon it if you would really like to work on it.

Comment 10

[Lebar]

Marco, I realize that you marked this as a good-first-bug, but since I worked on 469441 I thought that I would tie this one off as well. Unfortunately, I didn't check that someone else had asked to work on it.

Comment 11

[Marco Bonardo [:mak]]

Hello, sorry about that, bugs are usually assigned to the first person posting a patch, it's an automated task.
It is a good habit to check comments before starting the work on a bug, but with such short intervals it's complicate and doesn't always work.
No worries anyway, you can find more tasks at https://codetribute.mozilla.org/projects/ff, can't wait to see your first contribution!

Comment 12

[fatimaolasunkanmi01]

Hi Mark, I want to be sure if I have been assigned to work on this because my name is not reflecting

Comment 13

[Marco Bonardo [:mak]]

(In reply to fatimaolasunkanmi01 from comment #12)

Hi Mark, I want to be sure if I have been assigned to work on this because my name is not reflecting

No, I'm sorry, bugs automatically assign to the author of the first patch, please look for a different task from the list.

Comment 14

[fatimaolasunkanmi01]

okay thank you

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/5243c0c31233
Changed downloads context menu string for non-Mac from "Open Containing Folder" to "Show in Folder" to align terminology. r=mak,fluent-reviewers,flod

Comment 16

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/5243c0c31233