Get rid of the term "Directory" in favor of "Folder" where it makes sense




7 years ago
10 months ago


(Reporter: Rimas Kudelis, Unassigned)


(Blocks: 1 bug, {polish})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)




(2 attachments)



7 years ago
+++ This bug was initially created as a clone of Bug #559501 +++

Graphical Linux environments, just like Windows and Mac, use the term "folder" in preference to the term "directory". I think the term "folder" would look better in any GUI context, including this one. I would even go as far as suggesting to replace most occurences of the word "directory" with "folder". At least that's what I've done in my locale. It looks like the Wikipedia article linked above supports this position.

Comment 1

7 years ago
Created attachment 596283 [details]
Mentions of Folder in Gnome UI

Here's a screenshot from Gnome3 Nautilus. As you can see, it uses the word "Folder".

Comment 2

7 years ago
Yes, konqueror (KDE3) does it too. But console programs (like mc) use "Directory".

Maybe it is because of the difference between Folder and Directory as exmplained in the wikipedia link. Console programs usually display the raw filesystem hierarchy. Desktop environment file managagers are more prone to mangling the real hearchy a bit, show only some interpretation of it (hide files etc), use virtual folders and such.
So the UI people should decide where FF/TB stays in this dilema. Showing the real contents of profile directory can be considered to be the low-level filesystem approach. However, clicking the button will probably open it in some graphical file manager that will call it a Folder.
Keywords: uiwanted, ux-consistency

Comment 3

7 years ago
We (Mozilla) produce GUI applications, which, like you said, would most likely open a GUI file manager to display the contents of Profile folder. I'd say it's pretty clear on which side we are.
Sure, let's use "Folder" everywhere.
Keywords: uiwanted, ux-consistency


6 years ago
Blocks: 721332

Comment 5

6 years ago
Created attachment 597366 [details] [diff] [review]
Patch, v1

This is a rough patch for mozilla-central. I have sorted the files manually, so that relevant L10n and code are next to each other.

After this, the only string that still has word "Directory" in it is this one in security/manager/locales/en-US/chrome/pipnss/

CertDumpSubjectDirectoryAttr=Certificate Subject Directory Attributes

and I suppose, it should be left as is.
Attachment #597366 - Flags: review?(


6 years ago
Summary: On about:support, "Profile Directory" should be "Profile Folder", in ALL operating systems → Get rid of the term "Directory" in favor of "Folder" where it makes sense

Comment 6

6 years ago
Looking at the patch myself now, I found that in aboutSupport.dtd we used "Open Directory" in Unix, yet "Show Folder" in Windows. I left "Show Folder" in my patch, but now I'm wondering whether or not "Open Folder" would be better.

Comment 7

6 years ago
I don't really agree with this (I am old-school command line type) but probably can't swim against the flow here.
Changing the string IDs will break Thunderbird's about:support so please when you get review for this do not check it in immediately. I will prepare the needed patch for TB and they must then be checked in simultaneously.
Assignee: nobody → rq

Comment 8

6 years ago
I think the same should be done with comm-central anyway...

Comment 9

6 years ago
Yes, but most can be done in a separate bug later.

But at least the /toolkit/locales/en-US/chrome/global/aboutSupport.dtd strings are shared with comm-central and will break it immediately.
Er, by "everywhere" I meant "in about:support, on every platform". I don't really think we should be replacing it across the source tree.
Attachment #597366 - Flags: review?( → review-

Comment 11

6 years ago
(In reply to Gavin Sharp (use for email) from comment #10)
> Er, by "everywhere" I meant "in about:support, on every platform". I don't
> really think we should be replacing it across the source tree.

Er, why not?..
Because there's little benefit (some of the strings you're changing aren't even exposed to users) and changing code has inherent risks.

Comment 13

6 years ago
Rimas, will you reduce the patch now?

Comment 14

6 years ago
No, but anyone is free to cherry-pick whatever subset of it they find acceptable.
Assignee: rq → nobody


2 years ago
Depends on: 1300562
You need to log in before you can comment on or make changes to this bug.