Change "Open containing folder" string to "Show in folder"
Categories
(Firefox :: Downloads Panel, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox95 | --- | fixed |
People
(Reporter: RT, Assigned: lebar, Mentored)
Details
(Keywords: good-first-bug)
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
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.
Reporter | ||
Comment 1•3 years ago
|
||
See also https://bugzilla.mozilla.org/show_bug.cgi?id=469441#c72 where we'll be using a similar label for consistency
Comment 2•3 years ago
|
||
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.
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•3 years ago
|
||
(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.
Reporter | ||
Comment 5•3 years ago
|
||
(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•3 years ago
|
||
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•3 years ago
|
||
Marco Bonardo [:mak] kindly assign this task to me
Updated•3 years ago
|
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.
Assignee | ||
Comment 10•3 years ago
|
||
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•3 years ago
|
||
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•3 years ago
|
||
Hi Mark, I want to be sure if I have been assigned to work on this because my name is not reflecting
Comment 13•3 years ago
|
||
(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•3 years ago
|
||
okay thank you
Comment 15•3 years ago
|
||
Comment 16•3 years ago
|
||
bugherder |
Description
•