Closed Bug 1729447 Opened 9 months ago Closed 7 months ago

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

Categories

(Firefox :: Downloads Panel, task, P2)

task

Tracking

()

RESOLVED FIXED
95 Branch
Tracking Status
firefox95 --- fixed

People

(Reporter: RT, Assigned: lebar, Mentored)

Details

(Keywords: good-first-bug)

Attachments

(1 file)

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.

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

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.

Mentor: mak
Severity: -- → S4
Type: defect → task
Keywords: good-first-bug
Priority: -- → P2

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.

(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.

Flags: needinfo?(rtestard)

(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.

Flags: needinfo?(rtestard) → needinfo?(mwalkington)

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.

Flags: needinfo?(mwalkington)

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

Assignee: nobody → lebar
Status: NEW → ASSIGNED

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.

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.

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!

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

(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.

okay thank you

Pushed by mak77@bonardo.net:
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
Status: ASSIGNED → RESOLVED
Closed: 7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 95 Branch
You need to log in before you can comment on or make changes to this bug.