Style guide
General
Case
All text is to be written in sentence case. This includes all paragraphs, headings, and page titles.
Proper nouns and abbreviations should be capitalized according to the prevailing form used on the Wikipedia page of the topic in question.
Import the MusicXML file. ✅ MusicXML is capitalized
Customize the user interface (UI). ✅ UI is capitalized and user interface is not
Available in braille and Modified Stave Notation. ✅ MSN is capitalized and braille is not
Contractions of everyday speech should not be capitalized.
A quarter note (aka crotchet) is a musical duration. ✅ aka is not capitalized
UI labels
When writing instructions for the user, text that appears in MuseScore's user interface should be copied verbatim, including any capitalization, and highlighted in bold without enclosing quotation marks.
Press the Not now button. ✅ Not now is bold and capitalized like in the application
Arrows in UI paths
Type -> to describe the path through submenus or through the hierarchy of a dialog. GitBook will format this as a single arrow character, though in editing mode it appears as separate characters. Since the text either side will be styled in bold (as all text from the UI should be), keep the arrows bold too.
Choose File -> Save other -> Save a copy... ✅
Uncheck Style -> Notes -> Shorten stems. ✅
Bullet points
Bullet points (aka unordered lists) are used for listed content that is not an ordered process.
If the contents of a group of bullet points are not complete sentences, there's no need to use periods.
Dynamics
Accidentals
Articulations ✅ No periods
When bullet points are complete sentences, use periods at the end of each sentence, even if there is only one.
This is a one-sentence bullet point, with a period at the end.
This is a bullet with two sentences. Periods are included after every sentence. ✅ Full sentences require periods
It's a common pattern to have some bolded text at the beginning of a bullet followed by a colon. In this case, the colon should be bolded too and the first character after the colon should be capitalized.
Bullet: This is a good example. ✅ The colon is bold and 'This' is capitalized
Bullet: this is a bad example. ❌ The colon is not bold and 'this' is not capitalized
Numbered lists
Numbered lists (aka ordered lists) are used for listed content that must be done in sequence. For explanations of how to execute a task, try to keep it to one sentence per number, and use periods at the end of each one.
Think of what to say.
Express each step a short sentence with a period at the end.
Finish the list. ✅
Hyperlinks
Where appropriate, hyperlinks may be added to key words or phrases in ordinary text, which should be written to make sense without the link. In general, the full URL should not be displayed.
Watch the tutorial video. ✅ Text makes sense without the link
Watch the tutorial here. ❌ Text wouldn't make sense if the link was removed
Watch it at https://www.youtube.com/watch?v=z4Ecaaqwg8U. ❌ Don't show the URL
Plain domain names should be captalized like the brand name. The top-level domain (TLD, e.g. .com, .org, .co.uk, etc.) should be omitted unless there's a good reason to include it.
Find us on Facebook and YouTube. ✅ Omit .com TLDs for these popular sites
Listen on Audio.com. ✅ TLD is part of the website's branding
Visit MuseScore.org. ✅ TLD is necessary to distinguish from MuseScore.com
Download the installer from MuseHub.com. ✅ Referring specifically to the website
Get the sounds in MuseHub. ✅ Referring to the app (but linking to the website)
Keyboard shortcuts
Keyboard shortcuts should be formatted as follows:
Press Shift+1—9. ✅ en-dash indicates range
Press Ctrl+Shift++/- (Mac: Cmd+Shift++/-). ✅ slash indicates alternatives
Modifiers should be written in this form and in this order for each platform:
Windows/Linux: Win+Ctrl+Alt+Shift+Fn+... ✅
Mac: Ctrl+Cmd+Option+Shift+Fn +... ✅
In Linux-specific instructions, the Win key should be written as Super.
Keys that type printable characters should be represented by that character.
. , ; ' [ ] / \ - = ` etc. ✅
All non-printing keys should be referenced by their (possibly abbreviated) name rather than by a symbol. This includes the cursor keys.
Space Backspace Del Ins Esc Return Up Down Left Right PgUp PgDn Home End Menu Caps Lock ✅
Typed characters
Typed sequences should usually be formatted as inline code, even if it's just a single character.
To enter a double flat, type
bb. ✅ Inline code (single element)
Occasionally, it may be preferable to show the actual keys pressed, formatted as keyboard shortcuts rather than as inline code.
To enter a double flat, type B B. ✅ Keyboard keys (space between each key)
Structure
Pages
Page titles
Page titles should be relatively short. Ideally the title should fit on one line in the Summary on the left of the screen, although this may not always be possible. Bear in mind that page titles may be significantly longer when translated to other languages besides English.
Tips to keep page titles short:
Avoid saying "score" (e.g. "Selecting elements", not "Selecting elements in the score")
Avoid saying "MuseScore" (e.g. "Upgrading", not "Upgrading MuseScore Studio")
Subpages
When subpages are used, only one level of subpages may be used. Never create a subsubpage.
Parent pages should have very short titles because its title appears in the URLs of all its subpages.
In general, we prefer to use groups rather than subpages, to avoid nesting in the Summary.
Groups
Group names should be written in sentence case – the ALL CAPS styling is handled by GitBook automatically.
Groups should have very short names. This is because the group name appears in the URLs of all pages within the group.
It is possible to edit the group slug to make it shorter than the actual group name. However, in general, this should not be done. Instead, the group name should be made as short as possible.
Last updated
Was this helpful?