Closed Bug 1541411 Opened 8 months ago Closed Last month

Some DevTools labels should use Title Case in English locale

Categories

(DevTools :: General, task, P3)

task

Tracking

(firefox71 fixed)

RESOLVED FIXED
Firefox 71
Tracking Status
firefox71 --- fixed

People

(Reporter: fvsch, Assigned: aka84, Mentored)

Details

(Keywords: good-first-bug)

Attachments

(2 files)

We have a number of labels in DevTools which are using sentence case ("This is a label") instead of the expected Title Case "This Is a Label").
Guidelines: https://design.firefox.com/photon/copy/capitalization.html

We should fix those labels to make the UI more consistent.

I'm not sure about tooltips. Here are a few from Inspector:

  • Title case: "Create New Node".
  • Sentence case: "Grab a color from the page", "Toggle on the 3-pane inspector", "Add new rule", "Toggle pseudo-classes", "Toggle classes", "Highlight all elements matching this selector", "Click to open the color picker, Shift+Click to change the color format".

Tooltips can be short but oftentimes they're longer or more detailed labels than a "primary" label. Maybe sentence case makes sense here?

Inspector

  • Computed: "Browser styles"
  • Fonts: "All fonts on page", "Font preview text"
  • Layout: "CSS Grid is not in use on this page" -> keep the current case, but it needs a final dot to be consistent with similar messages in Layout>Flexbox and in Fonts.

Console

  • "Filter output"
  • All the labels in the context menu: "Store as global variables", "Copy message", "Copy object", "Select all", "Export visible messages to clipboard", "Open in sidebar"

Debugger

Basically Debugger is 100% sentence case, except for the "XHR Breakpoints" label? Is that desirable?

  • Sources context menu entries
  • Tabs context menu entries
  • Editor context menu entries
  • "Watch expressions", "Call stack"
  • "Pause on exceptions", "Pause on caught exceptions"
  • "Pause on any URL", "Break when URL contains"
  • etc.

Style Editor

  • Settings menu: "Show original sources", "Show @media sidebar"
  • Editor context menu: "Jump to line"
  • Media query sidebar: "@media rules" (maybe "Media Queries" here?)

Network

Toolbar:

  • "Disable cache"
  • "No throttling"

Headers tab:

  • "Request method"
  • "Request address"
  • "Status code"
  • "Filter headers"
  • "Response headers"
  • "Request headers"
  • "Raw headers"

Cookies tab:

  • "Filter cookies"
  • "Response cookies"
  • "Request cookies"

Params tab:

  • "Filter request parameters"
  • "Query string"

Response tab:

  • "Response payload"

Timings tab:

  • "DNS resolution"
  • "TLS setup"

Storage

Cookies:

  • "Filter items"
  • "Expires on" (rule = don't capitalize prepositions unless they're the first or last word of the text element)
  • "Last accessed on"

Victoria, do you want to chime in on which rule we should apply for different text elements?
I don't think we want Title Case on all the things.

Do use title case for:

  • Tabs
  • Toolbar buttons
  • Toolbar checkbox labels
  • Text input labels (including placeholder labels)
  • Accordion headers
  • Other headings (e.g. in Preferences)
  • Context menu items
  • Key labels in non-code key: value displays (e.g. in Fonts, or Network request details)

Use sentence case for:

  • Informative messages (e.g. "Select a Flex container or item to continue.")
  • Full sentences
  • Tooltips?
Type: defect → task
Flags: needinfo?(victoria)

Thanks for filing this and all the attention to detail!

For tooltips, sounds like sentence case is the way to go. Firefox does use a little capitalization in these if it's for a product name. E.g. in the hamburger menu there's "Open Sync preferences."

So the one tooltip that could possibly be changed: Capitalize "Inspector" in "Toggle on the 3-pane inspector."

Media query sidebar: "@media rules" (maybe "Media Queries" here?)

"Media queries" would be great

Everything else you mentioned sounds good.

Flags: needinfo?(victoria)

Note: The "title case vs sentence case" guidelines are a very English thing, so I don't think they would require updates in translations.

Mentor: florens
Keywords: good-first-bug
Priority: -- → P3

Hi,
I'm very new to the open source community and would love to be mentored on how to get started with this. Thanks!

Hi v.tank. The first step to get started is to check out the Firefox codebase. Firefox is using Mercurial, which is an alternative to Git. We have a "getting started" guide here: https://docs.firefox-dev.tools/getting-started/build.html

One bit of advice: you will only need "artifact builds", which are much faster than full builds, for this work. So when setting up, before building for the first time using the ./mach build command, I highly recommend following the steps in the Artifact Builds section.

The whole process is a bit long, you may need a few hours to get things right. If at any point you are stuck, you can ask for help on the Firefox DevTools slack at https://devtools-html-slack.herokuapp.com/

Once setup, most of the files you will need to change are in the devtools/client/locales/en-US directory. You can see its current content online here:
https://searchfox.org/mozilla-central/source/devtools/client/locales/en-US
You can use any code editor to edit them (VS Code, Sublime Text, any big IDE, etc.).

I think we should break the work by DevTools tool (also called a "panel"). Maybe start with the Console?
So the first step, after you've successfully built Firefox locally, would be to edit a few of the reported strings in devtools/client/locales/en-US/webconsole.properties, build and run Firefox again (./mach build && ./mach run), and check in the Console that the result looks okay.

Does this look manageable? I know the initial setup can be difficult, but feel free to ask questions here or on Slack!

According to the "Changing existing strings" section of the Localization documentation, we don't need to change the identifiers (which would invalidate existing translations).

Hi, it seems this bug is still open, is it ok if i take a shot at it as my first contribution? Can I get it assigned to me?

Thanks!

Sure! Great to have you on board :)

Have you seen the Getting Started documentation yet?
Setting up to build Firefox locally (so you can see and check your changes) can take a little while, up to a few hours, and if you're having issues you can ask for help in the DevTools slack.

For this type of work you will probably want to configure "artifact builds" to avoid building a lot of C++ code to see your changes. So when following the docs, before running the first ./mach build command, make sure you configure artifact builds first.

There's a lot of stuff referenced in this bug, so if you want to get started with fewer fixes you can maybe focus on the "Inspector" and "Style Editor" panels for now. In any case I would leave Debugger aside initially.

Assignee: nobody → alever84

thanks a lot! I had the whole local env set up with git (python bootstrap.py --vcs=git), but after reaching out on the slack channel about how to work with branches and commits, it was suggested that I should use Mercurial instead. So I'll have to spend some time familiarizing with it because I have never used it unfortunately. Hope to give you an update soon!

(not sure why I can't edit my previous comment)

after reaching out on the slack channel about how to work with branches and commits

Thought might be useful to reference here my slack comment: https://devtools-html.slack.com/archives/C3VTWQ4KZ/p1570621970003500

I'm currently pointing to bookmarks/central (got automatically pointed to it after following the whole "building firefox" process), and now i'm not sure if

  1. it's the correct branch to start from
  2. what's the expected feature branch name
  3. what's the expected format for a commit's message/title

wasn't able to find any relevant information on https://docs.firefox-dev.tools/ (there were a couple of promising links on https://docs.firefox-dev.tools/contributing/code-reviews-checklist.html but they seems to be out of date)

As additional information, I'm using the mozilla-unified repo, is that correct? I'm asking because on https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmozilla/unifiedrepo.html#unified-repository-on-hg-mozilla-org it's stated that it's a read-only repo

https://hg.mozilla.org/mozilla-unified is a read-only unified repository containing all of the commits on the default branch

Thanks for the help!

Enforced Title Case on all the labels listed in the bug description

About the "Debugger" panel: this was the only panel where the list of labels was left open-ended, so I did my best to spot all cases where the labels needed to be amended, but I'm pretty sure I still missed some (I'm not familiar with all its nooks and crannies)

Saving Alessandro's changes to the Debugger labels for later.

Changing the Debugger labels invalidates all the Debugger component snapshots, and updating them would result in a very big patch. Since Alessandro wasn't sure all Debugger labels were updated by their patch, let's focus on the other panels here, and we'll do a separate bug for the Debugger.

Keywords: checkin-needed

Pushed by csabou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1331f32961e8
Enforce Title Case on labels across panels. r=fvsch

Keywords: checkin-needed
Status: NEW → RESOLVED
Closed: Last month
Resolution: --- → FIXED
Target Milestone: --- → Firefox 71
You need to log in before you can comment on or make changes to this bug.