Content style guide

Legend

= Recommended style to use
= Style to avoid using

Contents

• Recommended resources
• Including new users and visitors
• Person-to-person communication
• Drupal-specific terms
• Referring to a specific module or theme
• Explaining version differences
• "Upgrade" vs. "update"
• Naming
• Industry-related words
• Acronyms and abbreviations
• Numbers and Dates
• Punctuation
• Symbols and Icons
• Writing style
• Voice
• British/American differences
• Miscellaneous notes on usage
• Titles and headings
• Procedure style
• HTML and code formatting
• Callouts: Warnings, version specific information, issue lists
• Links
• Paths and navigation

Recommended resources

• Elements of Style by Strunk and White (but Drupal's style guide overrides this when there are differences)
• Oxford American Dictionary
• The American Heritage Dictionary
• The Chicago Manual of Style (Our ultimate reference, but too expensive for the average user.)
• The Economist Style Guide (Wonderful book, but much information is British-based. Contains excellent section on British/American differences.)
• Wikipedia: Manual of Style (spelling) has a quick summary of the main differences between American and British English.

Back to top

Including new users and visitors

Intros to sections should use a welcoming, friendly tone, as one colleague to another, should specify what sort of things people can do to help Drupal (the site, community, or software), and should pay particular attention to indicating how even those new to Drupal can help.

For example, for new users visiting the Documentation landing page, it is encouraging to see words like these:

"If you are new to Drupal and have trouble understanding any part of the documentation, please [link text: notify those of us who work on this section] and clearly explain what you don't understand and why. We're happy to hear from you. Your contribution helps everyone at Drupal!"

Why say "notify those of us who work on this section" rather than just say "notify us"? It subliminally suggests that a group of people—volunteers rather than a distant or intimidating authority—write these pages.

Text like this has a brand-consistent voice, helps more people use Drupal—not just to download it—and shows new users how they can be important to Drupal. That, in turn, will encourage them to begin the journey to mastering Drupal and telling others about their great experience with Drupal.

Back to top

Person-to-person communication

Brand-consistent communication in forums, groups, and other points of contact is essential for reinforcing the brand and inspiring people to not only use the software but be passionately involved in the Drupal community.

Communication should, of course, be in your own voice. Make a point, though, to review your tone and choice of words before hitting "Send." Is your message off-putting, or does it encourage further communication, inspire participation, or include other people in a collaborative manner? Does it meet others halfway?

Even if other people irked you intentionally, did you rise above that and respond in a friendly way, or did you go down to their level? Remember that a forum or group may be the first page that a potential user sees at Drupal. This new person may hurry past any login and only start reading once reaching the forums. Be informative, kind, welcoming, informal, and full of good humor.

See www.alistapart.com/articles/puttingourhotheadstogether/ for ideas on how to use the forums for the betterment of Drupal, its brand, and its users (experienced and new).

Also see the comprehensive "forum tips" section, linked to in the introduction to the Forum.

Back to top

Drupal-specific terms

The first use of a Drupal-specific word on a page should be spelled out, even in a list. Thereafter, on that page, only the jargon, shorthand word, or nickname is necessary. This is important in the Forums, as well, because this may be the first entry point for a new user.

Drupal versions: Don't use phrases like "latest version" or "Drupal," as in "Download Drupal." Always call a version by its full name: Drupal 6.3. or Drupal 6.x or even Drupal version 6.3. Don't use "Update" when referring to versions of Drupal.

Download Drupal version 6.3 before using this module.
With Drupal 6.3, you can do amazing things.

Download the Drupal update before using this module.
In the latest version of Drupal, you can do amazing things.

Terminology is not capitalized unless you are referring to a section or page on the site.

Use modules to add features to your site.
Use Modules to add features to your site.

See the Modules page to discover new features for your site.
See the modules page to discover new features for your site.

Back to top

Referring to specific modules and themes

To refer to a specific module or theme, use this style:

the Contextual Links module

Start with "the", followed by the exact name of the module (what you would see on the Modules page) in Title Case, followed by the word "module" in lower-case. Similar for themes.

Back to top

Explaining version differences

When explaining differences between Drupal versions, there are two options. If a procedure or interface is substantially different between the two versions, consider creating two separate pages and noting the version at the end of the page heading. For example:

• Creating a widget (Drupal 6)
• Creating a widget (Drupal 5)

If there are only minor differences between versions (for example, if a step in a procedure is different), place each chunk of information in a separate paragraph and note the version at the beginning of the paragraph, more recent version first, earlier version second. For example:

• (Drupal 6) Click Y.
• (Drupal 5) Click X.

Back to top

"Upgrade" vs. "update"

An "upgrade" is an involved process that impacts the whole site, while an "update" is what happens to the code and database regardless of whether it's a major or minor release (for instance by dropping in a replacement file and running update.php). When describing processes for end-users or developers to "update" or "upgrade" core, modules, and themes, be as consistent as possible using these terms. Learn more about major and minor releases.

Upgrade

"Upgrade" should be used only for the act of performing a major version upgrade, the process of moving between major core releases. For example:

When upgrading your site from Drupal 6.x to Drupal 7.x, be sure to fully back up your site before beginning.

When you upgrade Drupal core from 6.x to 7.x, you must also update each module you have installed, as well as any themes that are not part of core.

When you receive a security update notice, be sure to upgrade any affected modules.

Update

"Update" on the other hand, should be used for minor version updates or the task of modifying a module/theme you maintain to a subsequent release. As part of the overall upgrade process, you also do a lot of updating; replacing contributed modules with new versions, updating custom themes or modules, updating site configuration. For example:

You or your development team should update your installed core version to the next minor release (6.18 to 6.19, or 7.0 to 7.2).

You or your development team should update a contributed module to the next minor release (6.x-2.1 to 6.x-2.2)

You should update a contributed module for a major release (6.x-2.1 to 6.x-3.2, and also 6.x-2.1 to 7.x-3.2, although the latter is part of the major site upgrade process).

A hook_update_N() (an update hook) may be run both for minor and major releases, for both core and contributed modules/themes, and always via update.php

Module maintainers will be updating their modules for major Drupal core releases.

Module maintainers will be updating their modules for major Drupal contributed module releases (eg. Views 3, Token 2).

It is important to inform your client that their site needs security updates.

When Drupal 8 is released, you will need to prepare to update your site.

You will need to do full updates of all of the Drupal 5 sites you maintain when Drupal 7 is released, as that version will no longer be supported.

Port

Alternately, for developers, the term "to port" can be used for the act of updating their modules between major versions of Drupal, for example "I have yet to port my module to Drupal 7".

Back to top

Naming

When naming modules, themes, and other features, avoid jargon and Drupal nicknames as best you can, as well as names with private meanings. It alienates the new user.

Timekeeper
Beastmaster_IQ4
ab.cron_cctime

Back to top

Industry-related words

Correct:

• Ajax, not AJAX or ajax
• back end, front end, unless describing a noun. Correct: Change the front end. He's a front-end designer.
• blog (not weblog)
• Drupal, not drupal
• (e-words are always lowercase, except at the beginning of a sentence or in a heading)
• e-commerce, not ecommerce
• e-learning, not elearning
• email, not e-mail
• FAQ stands for Frequently Asked Questions; don't add an "s" to pluralize it
• homepage, not home page
• HowTo:, not HOWTO:
• HTML, not html
• installation profile, not install profile
• internet, not Internet
• JavaScript, not Javascript
• log in (verb): Ex. Log in by entering your username.
• login (noun): Ex. Use the login section.
• MySQL
• nonprofit
• online, not on-line
• page view
• PHP, not php
• server-side, not server side or serverside
• sidebar
• style sheet, not stylesheet
• sub-page
• the web, not the Web
• URL, not url
• username, not user name
• web page
• web publishing
• web server
• web, not Web
• webmaster
• website or site, not web-site or web site
• XHTML, not xhtml

Exception:

• When a word is lowercase, such as web, it uses an uppercase first letter when it is the first word in a sentence or heading.

Back to top

Acronyms and abbreviations

Always abbreviate identification/identifier as ID, not id. This is standard English (check your favorite dictionary -- id is a psychological term).

Pluralize them by adding an "s" without an apostrophe. Only use the apostrophe if you're describing something possessed by the acronym.

URLs, DVDs
URL's, DVD's
The DVD's surface is scratched.

The first use of an acronym or abbreviation on a page should be spelled out, even in a list. Thereafter, on that page, only the acronym or abbreviation is necessary. This is important in the Forums, as well, because this may be the first entry point for a new user.

The Content Construction Kit (CCK) allows you to add custom fields to nodes using a web browser. Once you update the core CCK modules and ensure that they are working properly, add other CCK modules to the modules folder.

Exception: You don't need to spell out widely-known acronyms and abbreviations that are even familiar to non-technical visitors.

Examples: RSS, URL, DVD

Back to top

Numbers, Dates and Time

• A billion is defined as an American billion: 1,000,000,000
• Thousands should be separated by commas, i.e 100,000

Dates

Express dates either in full (December 6, 2008) or use the proper ISO date format: yyyy-mm-dd, as in 2008-12-06, depending on where it is being used. This may be unfamiliar to some users of American English, but the ISO standard is the widely-accepted date format for modern software. An American event probably would use the full word version (Drupalcon, December 6-7, 2008) whereas a date for an entry or update might use the ISO version—but keep pages consistent.

Dates in full: December 6, 2008
ISO standard: 2008-12-06

Back to top

Time

ISO 8601 uses the 24-hour clock system. The basic format is [hh][mm][ss] and the extended format is [hh]:[mm]:[ss], for example 13:47, or 13:47:30.

ISO standard: 13:47
1:47 PM

Back to top

Punctuation

Use curly (smart) quotes unless you are providing code examples.

Use only one space after a period.

Don't use the ampersand in text. Use it only in code examples or when referring to a page title that uses an ampersand (Community & support). The only places ampersands should be used in titles are in the main navigation buttons and in the title of each corresponding page.

Community & support is a legitimate title because it is in the main navigation. The title of that landing page should also be Community & support.

Drupal's most popular modules and themes

Drupal's most popular modules & themes

If a phrase in parentheses is within a sentence, put the period at the end of the sentence, not within the parentheses. If the phrase in parentheses isn't within a sentence, place the period within the parentheses.

(We are new here and didn't know what we were doing.)

I don't know why we did that (I guess we didn't know what we were doing).

Hyphens

Use em dashes (HTML entity 8212, "—") for abrupt breaks in a sentence, to temporarily change subject within a sentence, for clarity, to draw attention to a point, or to signify the origin or author of a quotation.

• Don't use double hyphens; use the HTML entity.
• Don't place spaces on either side. There shouldn't be any space between the word or words next to an em dash and the en dash.

Use an en dash (HTML entity 8211, "–") to indicate a range of numbers or dates. (See www.alistapart.com/articles/emen/ for more information about the subject of dashes and hyphens.)

Punctuating lists:

Precede an ordered or bulleted list with a sentence or phrase ending in a colon.

In Groups, you can：

• Get to know other Drupal users．
• Collaborate on projects in a small group．
• Voice your opinion on a particular project．

Begin each item with a capital letter (unless it is a product or company name that begins with a lowercase letter).

Complete sentences in a list should have a period at the end. If a line item is not a complete sentence, do not use a period. If you are breaking a sentence into a list, as in the first example in this section (In Groups), periods aren't necessary.

Be consistent, if possible, when writing the items in the list. Make them "parallel." In the first example, Get, Collaborate, and Voice are the same form of verb.

• Getting to know other Drupal users
• Projects that need lots of people
• State your opinion

Back to top

Symbols and icons

Provide a key or footnote on every page that uses a symbol, even a symbol that seem obvious to you. For example, the symbols used on the Modules page (e.g., checkmarks [1]) should be explained in a short footnote.

Back to top

Writing style

• Keep sentences to 15 words or fewer. Don't be wordy. Long sentences are difficult to understand.
• Spell check.
• Avoid slang terms. Be sure any English-language idioms you use are common and well-known. This benefits all readers, but especially Drupal users with a first language other than English.
• Do not assume that the reader will be familiar with cultural references.
• Use language that includes people with vision or hearing disabilities wherever possible. For example, "You will see a block at the top of the page ..." assumes that the reader can see. It's better to write "A block is displayed at the top of the page ...". .

Back to top

Voice

Reinforce the Drupal brand: Scan the beginning of the Drupal brand style guide before writing. Anything written at Drupal.org becomes part of the Drupal experience and should convey the Drupal spirit.

• Be clear, simple, and concise.
• Be respectful, honest, and approachable.
• Be engaging, welcoming, lively, and fun where appropriate.

New to themes? Here's [link text: how to get started]. Only cut-and-paste PHP knowledge needed. Questions? Find people happy to [link text: help in the forums] or [link text: hire a developer].

You should already know about themes in general. If you want to find out more, read that section because it will give you all the details you need. You will need to know some PHP but not much. If you aren't an experienced developer, I don't think this section will help you very much and you probably should hire someone to do it for you.

• Use ordinary, everyday language instead of words that sound more elevated--they usually don't.

Use this to...

Leverage this to...

Utilize this to...

Know your audience: Tone of voice, use of jargon or Drupal nicknames, and complexity of language should be appropriate for the type of page:

• Major landing pages must be approachable and appropriate for a wide audience that could include beginners, company managers, designers, developers, business owners, first-time bloggers, tech-savvy entrepreneurs, educational organizations, or advanced Drupal developers. Keep them in mind.
• Deep-level pages (e.g., discussing the complexities of module-building), while still using the Drupal tone of voice, can be more complex and use jargon and "insider" names for Drupal functions and features.
• Use empathy: Put yourself in the place of the readers. Try to look at your text through the eyes of a variety of visitors.
• You don't need the word "Please" in order to sound friendly. At times, it will be appropriate; usually, it will not. It sometimes comes across as condescending.

Get them there: Ask yourself what visitors want to get done and help them get there quickly.

Short isn't always best: Concise (brief yet comprehensive) is good, but shortness? It depends. What does the user expect and need?

• If you are just trying to attract attention, do that, with a short, snappy headline. Snappiness, though, is not always necessary. To persuade someone or show Drupal's personality to a new visitor, use attractive, compelling words. To simply get someone to the proper destination, link text "See Documentation" is fine, and so is the heading "Documentation."
• If the user needs or is looking for a lot of information at this point, provide it. Don't be afraid to go into detail, no matter what advice you've read. With proper headings, whitespace, subheads, padding, links, short paragraphs, charts, and lists, length here is a good thing. Unnecessary words? Not good.

Open source not market-speak: Avoid fluffy sales talk. "We're great! Drupal is great!" "We're the best!" These sentences are only believed by those who write them, not those who read them.

• Words such as "very, really, truly" tend to weaken a statement, not strengthen it.

This module reduces the time you need to set up a forum.

The module really reduces the time you need to set up a forum.

Even better: This module reduces forum set-up time.

Edit and edit again: Strip away unnecessary words. Examine them. Is each one lively, direct, and doing a job? Or, is it empty or deadening? Because an informal voice is brand-consistent, complete sentences aren't always necessary:

"Can't find the answer?"

"Are you having trouble finding the answer to your question?"

PHP expertise necessary? Yes.

PHP expertise is necessary.

Expertise in the use of PHP is very necessary for using this module.

Think globally: Avoid phrases that aren't easily translated, such as puns and social or local references. Beware of wit or cleverness that won't have the same meaning in other countries. Light humor, in good taste, is good, but will it translate?
(PDF 514 MB)

(PDF 514 MB) Better get out the popcorn and watch The Big Lebowski while you're waiting for this bloody thing to download.

Be clear about benefits for the reader: Drupal is here to make people awesome at what they do. Using the word "you" can be powerful.

In general, use active, not passive, voice: In active voice, the subject performs the action ("The dog ate the bone."). In passive voice, the subject is the target of the action ("The bone was eaten by the dog.").

Don't twist sentences into knots trying to avoid this, though. Also, at times, passive voice emphasizes words that active voice would downplay. In that case, use passive voice, but, in general, use it sparingly.

You should clearly identify links.

Clearly identify links. ("You should" is implied.)

Links should be clearly identified. (Here, the links aren't doing something; someone is doing something to them.)

Click the download button to get the core files.

The download button should be clicked in order to obtain core files.

Quick Resource: https://owl.english.purdue.edu/owl/

Resource for variations in non-English languages: see Wikipedia: Voice (grammar)

Avoid first-person: Avoid first-person (I, we, my, our) on editorial/landing pages. Use "Drupal" instead. At times, because Drupal is community-based, use "we" to sound inclusive or to reinforce the community concept. Avoid first-person in sections such as Documentation or Modules, etc.

This module helps you add feature x.

I created this module to help you add feature x.

Drupal releases a new version every six months.

We release a new version every six months.

Things we made with Drupal (Exception to first person rule, on homepage. "We" conveys sense of real Drupal people with real stories.)

Balance the needs of new and experienced users. Provide links to additional or clarifying information new users may not know. At the same time, experienced users need quick steps.

User-test your writing: Choose at least one person from your intended audience to make sure directions are clear and complete, and the tone is correct. User-testing is critical for sections like Modules and Documentation. If it is written for a new user with basic skills, you should test it on new users with basic skills. They should be able to achieve the final goal just by reading and following the directions, without asking you any questions.

Back to top

British/American differences

Drupal uses American English rules for spelling and punctuation.

Spelling examples:

• Color, not colour
• Organize, not organise
• Gray, not grey
• Spelled, not spelt
• While, not whilst
• Center, not centre
• Meter, not metre

Treat companies and organizations, although made of groups of people, as single entities:

Microsoft has many products.

Microsoft have many products.

Harvard University has decided to close for the summer.

Harvard University have decided to close for the summer.

The Drupal community needs more money.

The Drupal community need more money.

Punctuation examples:

• Use a serial comma∶　It is a comma that separates all items in a list, including the final two (before the ， and). The exception is when two associated items that form a name or pair are on the list. These are not separated by a comma.

I like writing, reading, spaghetti and meatballs, bicycling, and receiving Christmas presents.

I like web designs by Happy Cog, Clearleft, Veerle and Geert at Duoh!, Airbag, and Mark Boulton Design.

I like apples, pears and pineapples.

• Don't use the serial comma in headings and titles.

When a colon precedes a full sentence or question, the first letter after the colon should be a capital letter.

Consider this: Cats are different from dogs.

Consider this: cats are different from dogs.

She wants many things for Christmas: boots, lingerie, shoes, perfume, and jewelry.

Quotation marks:

Single quotes are used only when a quote appears within a quote.

Mary said, "I don't know why she said 'No,' when I asked her."

Mary said, 'I love to attend Drupalcon.'

Final quotation marks in a sentence or phrase are used after the period or comma, even when naming something.

Add features to the Drupal core by using things called "modules."

Put quotation marks before semicolons, and colons.

Back to top

Miscellaneous notes on usage

Generally, when giving examples, use "such as" rather than "like."

Drupal.org has many sections, such as Features, Community & Support, Modules, and Documentation.
Drupal.org has many sections, like Features, Community & Support, Modules, and Documentation.
Many people, such as webchick and Dries, participate frequently in the forums.

Use "like" to replace "in the same way as."
Participate in the forums frequently, like webchick and Dries.

Alt attributes: All images, other than purely decorative ones (such as background colors) should be described using an alt attribute.

Back to top

Titles and headings

Use short descriptive titles to label a handbook entry. Titles should be 80 characters or fewer. Avoid redundancy; the words "Drupal" and "Handbook" should rarely be used in titles.

All main headings and subheadings use sentence caps: only the first letter of the first word is capitalized. Everything else except proper names is in lower case. (Drupal is a proper name.)

• Exception: The titles for individual features on the About Drupal page are all uppercase.
• Exception: Use "HowTo: {title}" (one word, capital T) for documentation pages that function as step-by-step recipe-type tutorials.
• Exception: The titles of major works of literature such as books, movies, and magazines follow the capitalization used by the actual book or magazine. These titles should also be emphasized using the <cite> tag.

Things we made with Drupal

We were watching The Lord of the Rings.

When referring to a title in the middle of a sentence, use the same capitalization that the title itself uses. If this creates confusion in meaning (as it may if it is unclear exactly where the title words end), the title may be set off with the <strong> element.

See the About page for more information.

Announcing a new O'Reilly Drupal book: Using Drupal

The What to do when confused page tabs can be useful.

The What to do when confused page tabs can be useful.

Put initial words in bold in sentences that begin with a description of the item in a list, or otherwise clarify the contents of a paragraph. Use the <strong> element for bolding words. Only use <em> if a particular word needs to be emphasized for a specific reason.

Even better: Make those initial words into a heading. See for yourself which looks better. If many headings break up a page too much, include the bolded words in the beginning of each sentence or item. If headings bring clarity to a page, use them instead.

See the administration section to learn how to configure and manage your site and use modules, blocks, permissions, and themes.

Administer your site

Learn how to configure and manage your site and use modules, blocks, permissions, and themes.

Avoid numbering child pages; page weights can properly order them, but this requires site maintainer rights. If you need pages reordered, make an issue stating which pages and the order you want them. If you do use numbering (e.g. temporarily) use "1." style numbering, not "1)" or "1-"

A heading should never be followed by another heading. For example, you should never start a page with a heading (other than what is in the page's Title field).

Mark headings with the appropriate "h" tag (<h2>, <h3>) not the <b> or <strong> tag. The <b> and <strong> tags do not have any semantic sense: they are for emphasis.

Never use the <h1> tag for headings. This tag is added automatically to the page title. If a page has major sections use <h2> instead and use <h3> for the subsections. Use of <h4> etc. should not be necessary. Never use heading tags for emphasis. These rules are important for enabling accessibility.

Never end a heading or page title with a period (.), colon (:), semi-colon (;) etc.

Back to top

Procedure style

For sequential steps, use a numbered (ordered) list. For a set of options, use bullets (unordered list). When describing actions, avoid unnecessary words.

Click x.
Drag x to y.
Click on x.
Drag and drop x to y.

Back to top

HTML and code formatting

A general drupal.org HTML reference provides example tags and examples of how they'll appear on the page.

Avoid the underline tag <u>; use emphasis <em> instead. The <em> tag is also used for things that must be in italics. Use the <cite> tag for book titles.

Use ordered lists <ol> for step-by-step instructions and for lists of items that have an order of priority. All other lists should be "unordered." However, it is often helpful to the reader if a list is still sorted in a way that is appropriate for the context (alphabetical, earlier to later etc.)

Enclose HTML code samples within <code> tags.

Enclose PHP code samples within <?php and ?> tags.

Back to top

Callouts: Warnings, notes, version specific information, and issue lists

The visual CKEditor toolbar provides several templates for giving small portions of content on a page more visual weight, such as:

• Warnings, notes, and reminders
• Information specific to some versions of Drupal or a module
• Lists of issues

To insert one of the templates in your page, select it from the list in the CKEditor toolbar 'Templates' button.

Keep accessibility in mind when writing the text in your callout. The meaning and context need to be clear, even without the callout styling, so that people using screen readers or custom CSS can still understand that this is a tip, warning, etc.

Here are a few examples of what this can look like in your page:

Back to top

Links

When embedding a link in a Handbook page, always make sure the link text describes the destination of the link. "Click here" is not a good description, because it does not tell the user where the link will take them. If you can't fully describe the destination of the link and still maintain good sentence flow, add a title tag. Title tags, used appropriately, are important for making the handbooks accessible.

Examples of link text:

how to organize a Drupal event (this is the best one, given the subject)

organize a Drupal event

visit this page

Drupal event

event

The best place to learn how to organize a Drupal event is on the Drupalcon homepage.

Do not repeat the same link text on the same page if it links to different destinations. (This is another good reason not to use "click here.") Someone who cannot see the page and is using a screen reader cannot tell which link goes where if the link text is the same for both.

Always warn users if clicking on a link will lead to a PDF or other download, including modules, etc. They may think they are clicking on something that merely provides more information, rather than immediately downloading a file.

[link text: Learn how to organize a Drupal event]. (PDF 3MB)

If the link text has punctuation at the end, be careful not to include the punctuation in the link itself. (See example above.)

Use relative links where possible.

　<a href="http://www.drupal.org/node/1234567">
　<a href="/node/1234567">

Embed links within normal descriptive body text.
　Drupal now uses Git as its <a title="An introduction to version control systems" href="http://www.example.com">version control system</a>

　Git rules! To learn about it <a href="http://www.example.com">click here</a>

Use 'example.com' as the domain name when describing an example domainname and www.example.com when using a Fully Qualified Domainname and do not use "yourdomain.com" or other creative domainnames, and embed the "link" in <code> to avoid it turning into a clickable links.

Use an IP address out of the RFC1918 IP space when you need to use an IP address, for example 10.2.3.4

Do not use target= attributes on links to make them open in a new window or tab. This is no longer considered to be good practice on the web in general.

Link to relevant documentation and forum posts wherever it would be helpful. Provide a link to any specific item only once, on its first occurrence in a page.

Glossary links:

• Link to a specific Drupal term:
  

  <a title="see Taxonomy" href="/node/937#t">Taxonomy</a>
  

• Link to a common expression used on Drupal.org:
  

  <a title="Find under A - List" href="/node/302232#a">AFAIK</a>
  

Back to top

Paths and navigation

When describing how to get to a specific user option in the interface (e.g., the "add vocabulary" option in the categories section of the administer screen) show the path needed to access the option using this format:

destination (<em>path > to > item > destination</em>)

Which will yield text that looks like this:

• destination (path > to > item > destination)

• Do not abbreviate words in the navigation path (e.g., use administer instead of admin).
• Menu items can move. So rather than just describing which menus or links to click, also include the path, using example.com for the web site (ex: path > to > item > destination, or http://example.com/path/to/destination). If you enclose your URL in a <code> tags, you will avoid having it turn into a clickable link.
• If the path in search leads through a sidebar note, include the sidebar heading or link in parentheses after the page's heading.

Home > Modules (sidebar) > Popular modules >

Back to top

[1] This is where the footnote explanation would go, if there were a real footnote for this page. — return to "Symbols and Icons".