Some people will read every word you write. Others will just scan. Help everyone by grouping related ideas together and using descriptive headers and subheaders.
Focus your message, and create a hierarchy of information. Lead with the main point or the most important content.
* Be consistent. Adhere to the copy patterns and style points outlined in this guide.
* Do not use contractions as they cheapen the content and provide difficulty for readers of other languages.
* Use the serial comma. Otherwise, use common sense. (Also known as the Oxford comma, it helps clarify when items in a list of three, four, or more things are their own items.)
* Do not use underline for emphasis, and do not use any combination of italic, bold, caps, and underline.
Many of these repeat or reinforce George Orwell's six rules from his essay "Politics and the English Language" (1946), and it is worth keeping all of them in mind, especially the last:
> (i) Never use a metaphor, simile or other figure of speech which you are used to seeing in print.
> (ii) Never use a long word where a short one will do.
> (iii) If it is possible to cut a word out, always cut it out.
> (iv) Never use the passive where you can use the active.
* Create a hierarchy, with the most important information first.
Place similar topics in the same paragraph, and clearly separate different topics with headings.
* Use plain language. Write short sentences and familiar words.
* Links should provide information on the associated action or destination. Avoid saying “click here” or “learn more.”
* Avoid using images when descriptive text will do.
* Avoid directional instructions or language that requires the reader to see the layout or design of the page.
* Label inputs on forms with clear names and use appropriate tags. Think carefully about what fields are necessary, and especially which ones you mark as required.
* Write briefly, but do not sacrifice clarity for brevity. You may need to repeat or add words to make the meaning of your sentences clear to a translator.
* **Authentic**. Write about what you are passionate about.
* **Useful**. Before you start writing, ask yourself: What purpose does this serve? Who is going to read it? What do they need to know?
* **Appropriate**. Write in a way that suits the situation. Just like you do in face-to-face conversations, adapt your tone depending on who you’re writing to and what you’re writing about.
Agaric's tone is usually informal, but it is always more important to be clear than entertaining. When you are writing, consider the reader's state of mind. Are they curious about a post on our blog? Are they distrustful after being burned by a previous vendor? Are they excited to be engaging in a redesign? Once you have an idea of their emotional state, you can adjust your tone accordingly.
Agaric has a sense of humor, so feel free to be funny when it is appropriate and when it comes naturally to you. If in any doubt, do not make the joke. Generally avoid humor in written communication to clients.
We write the same way we build software: with a person-first perspective. Whether writing for an internal or external audience, write for and about other people in a way that is compassionate, inclusive, and respectful. Being aware of the impact of our language will help make Agaric a better place to work and a better steward of our values in the world.
Do not refer to a person's ability unless it is relevant to what you are writing. If you need to mention it, use language that emphasizes the person first: "she has a disability" rather than "she is disabled." When writing about a person with disabilities, do not use the words "suffer," "victim," or "handicapped." "Handicapped parking" is OK.
Do not refer to a person's medical condition unless it is relevant to what you are writing.
If a reference to a person's medical condition is warranted, emphasize the person first. Do not call a person with a medical condition a *victim*. Instead, use *patient*.
Do not refer to a person's mental or cognitive condition unless it is relevant to what you are writing. Never assume that someone has a medical, mental, or cognitive condition.
Do not describe a person as "mentally ill." If a reference to a person's mental or cognitive condition is warranted, use the same rules as writing about abilities or medical conditions and emphasize the person first.
Adhering to certain rules of grammar and mechanics helps us keep our writing clear and consistent. This section will lay out our house style, which applies to all of our content unless otherwise noted in this guide. (We cover a lot of ground in this section—the search feature will help if you are looking for something in particular.)
Write for all readers. Some people will read every word you write. Others will just skim. Help everyone read better by grouping related ideas together and using descriptive headers and subheaders.
Focus your message. Create a hierarchy of information. Lead with the main point or the most important content, in sentences, paragraphs, sections, and pages.
Be concise. Use short words and sentences. Avoid unnecessary modifiers.
If there is a chance your reader will not recognize an abbreviation or acronym, spell it out the first time you mention it. Then use the short version for all other references. If the abbreviation is not clearly related to the full version, specify in parentheses.
If the abbreviation or acronym is well known to your full intended audience, like API or HTML in technical documentation, use it instead (and do not worry about spelling it out).
Sentence case capitalizes the first letter of the first word. We use sentence case for headlines, subheads, and headings as well as every other sentence. (We do **not** use title case, which capitalizes the first letter of every word except articles, prepositions, and conjunctions. Instead, we let the formatting of titles carry the weight and use the more natural sentence case.)
Do not capitalize words in the middle of sentences that are not proper nouns. We do not capitalize internet, web, or e-mail. For more, see the [word list](#word-list-specialized-vocabulary).
They are bad! Even though they may give your writing an informal feel, they provide difficulty for readers that do not speak English. You can make your writing informal without the use of contractions.
Spell out a number when it begins a sentence or is under ten. Ten to twenty is a judgement call (but usually spelled out if not paired with numerals). Otherwise, use the numeral. This includes ordinals, too.
Use an en-dash (–) to indicate a range or span of numbers. (On Mac: Option + `-` (dash). On Windows: Control + `-` (dash). On Debian or Ubuntu with compose key enabled: compose + `--.` (dash dash period).
Specify time zones when writing about an event or something else people would need to schedule. Since Agaric was founded and has several worker-owners in Boston, Massachusetts, we default to ET.
Abbreviate time zones within the continental United States as follows:
Eastern time: ET
Central time: CT
Mountain time: MT
Pacific time: PT
When referring to international time zones, spell them out: Nepal Standard Time, Australian Eastern Time. If a time zone does not have a set name, use its Coordinated Universal Time (UTC) offset.
Abbreviate decades when referring to those within the past 100 years.
the 00s
the 90s
When referring to decades more than 100 years ago, be more specific:
The apostrophe's most common use is making a word possessive. If the word already ends in an s and it is singular, you also add an 's. If the word ends in an s and is plural, just add an apostrophe.
Note the exception to this rule: the word **it**, which does not use an apostrophe for its possessive, for example: "Our competitor had all its clients' websites hacked." Agaric avoids contractions so we do not ever use **it's** but rather **it is**.
Apostrophes can also be used to denote that you have dropped some letters from a word, usually to match spoken language— an unofficial contraction. This is fine when quoting or paraphrasing and giving the feel of a statement is important, but do it sparingly.
Use an em dash (—) with a space after the dash to offset an aside. Use a true em dash, not hyphens (- or --). If the set-off phrase has the main part of the sentence continuing, do not include spaces around the em dash. If the set-off phrase ends the sentence, leave a space after the em dash.
* We could build immensely powerful movements from the ground up, if we had a way to agree how shared resources of movements—including communication channels—would be controlled.
* Migrate does almost all the work for us— we just need to create a Migration class and configure it using the constructor.
Ellipses (…) can be used to indicate that you are trailing off before the end of a thought. Use them sparingly. Do not use them for emphasis or drama, and do not use them in titles or headers.
* "Where did all those doughnuts go?" Christy asked. Lain said, "I do not know…"
Ellipses, in brackets, can also be used to show that you are omitting words in a quote.
* "When in the Course of human events it becomes necessary for one people to dissolve the political bands which have connected them with another and to assume among the powers of the earth, […] a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation."
Periods go inside quotation marks. They go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
* I ate a doughnut and a bagel. (The doughnut was Sam's.)
Use two spaces after a period between sentences. This will be ignored in HTML but gives the opportunity to begin using a ligature that provides slightly more space at the end of a sentence than in acronyms, to prevent ambigities in interpretation such as: "We went to the U.S. I told him."
Question marks go inside quotation marks if they are part of the quote. Like periods, they go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
Use exclamation points sparingly, and never more than one at a time.
Exclamation points go inside quotation marks. Like periods and question marks, they go outside parentheses when the parenthetical is part of a larger sentence, and inside parentheses when the parenthetical stands alone.
Never use exclamation points in failure messages or alerts. When in doubt, avoid!
##### Quotation marks
Use quotes to refer to words and letters, titles of short works (like articles and poems), and direct quotations.
Periods and commas go within quotation marks. Question marks within quotes follow logic— if the question mark is part of the quotation, it goes within. If you’re asking a question that ends with a quote, it goes outside the quote.
Use single quotation marks for quotes within quotes.
* Who was it that said, “A fool and his doughnut are easily parted”?
* Brad said, “A wise man once told me, ‘A fool and his doughnut are easily parted.’”
Go easy on semicolons; they usually support long, complicated sentences that could be simplified. Try an em dash (—) instead, or simply start a new sentence.
If your subject's gender is unknown or irrelevant, use "they," "them," and "their" as a singular pronoun. Use "he/him/his" and "she/her/her" pronouns as appropriate. Do not use "one" as a pronoun.
The first time you mention a school, college, or university in a piece of writing, refer to it by its full official name. On all other mentions, use its more common abbreviation.
Per AP Style, all cities should be accompanied by their state, with the exception of: Atlanta, Baltimore, Boston, Chicago, Cincinnati, Cleveland, Dallas, Denver, Detroit, Honolulu, Houston, Indianapolis, Las Vegas, Los Angeles, Miami, Milwaukee, Minneapolis, New Orleans, New York, Oklahoma City, Philadelphia, Phoenix, Pittsburgh, St. Louis, Salt Lake City, San Antonio, San Diego, San Francisco, Seattle, Washington.
On first mention, write out United States. On subsequent mentions, US is fine. The same rule applies to any other country or federation with a common abbreviation (European Union, EU; United Kingdom, UK).
Our company's legal entity name is **Agaric, LLC**. Our trade name is **Agaric**. Use **Agaric, LLC** only when writing legal documents or contracts. Otherwise, use **Agaric** or **Agaric Technology Collective**.
Honor companies' own names for themselves and their products. Go by whatever is used on their official website. Unless they end with an exclamation point ('!'); that is absurd and will not be respected!
Do not use underline formatting, which typically indicates a link, and do not use a combination of italic, bold, or all capital letters.
## Write positively
Use positive language rather than negative language. One way to detect negative language is to look for words like "cannot" or "do not" (or the contractions we want to remove anyway, "can't" and "don't").
What: Short, encouraging message letting the user know they’ve accomplished something in the app
Length: 5-20 words
Example: Excellent! Your account has been created
##### Error or failure message
What: Short message that alerts the user to a problem in their account or on their site
Length: 20-75 words
Example: Looks like you may have left our default header content unmodified. Specifically, we still see ‘Use this area to offer a short preview’ in the pre-header/header area.
Example: The City of Camrbidge uses Agaric's Find It platform to make it easier for people to find activities, events, and resources. Here is how it works: https://agaric.coop/work/find-it-cambridge
Every piece of content we publish is supported by a number of smaller pieces. This section lays out our style in regards to these web elements, and explains our approach to the tricky art of SEO.
Alt text is a way to label images, and it is especially important for people who can’t see the images on our website. Alt text should describe the image in a brief sentence or two.
Buttons should always contain actions. The language should be clear and concise. Capitalize every word, including articles. It is OK to use an ampersand in button copy.
Standard website buttons include:
* Log In
* Sign Up Free
* Subscribe
* Email Us
#### Checkboxes
Use sentence case for checkboxes.
#### Drop-down menus
Use title case for menu names and sentence case for menu items.
Form titles should clearly and quickly explain the purpose of the form.
Use title case for form titles and sentence case for form fields.
Keep forms as short as possible.
Only request information that we need and intend to use. Don’t ask for information that could be considered private or personal, including gender. If you need to ask for gender, provide a field the user can fill in on their own, not a drop-down menu. (Or use a comprehensive solution like the [Drupal gender field module](https://www.drupal.org/project/gender).)
Headings and subheadings organize content for readers. Be generous and descriptive.
Headings (H1) give people a taste of what they’re about to read. Use them for page and blog titles.
Subheadings (H2, H3, etc.) break articles into smaller, more specific sections. They give readers avenues into your content and make it more scannable.
Headings and subheadings should be organized in a hierarchy, with heading first, followed by subheadings in order. (An H2 will nestle under H1, an H3 under H2, and on down.)
Include the most relevant keywords in your headings and subheadings, and make sure you cover the main point of the content.
Use title case, unless the heading is a punctuated sentence. If the heading is a punctuated sentence, use sentence case. Use sentence case for subheadings regardless of end punctuation.
Provide a link whenever you’re referring to something on an external website. Use links to point users to relevant content and trusted external resources.
Do not include preceding articles (a, an, the, our) when you link text. For example:
Do not say things like “Click here!” or “Click for more information” or “Read this.” Write the sentence as you normally would, and link relevant keywords.
Links should look different than regular copy, strong text, or emphasis text. They should have a hover state that communicates they are interactive, and should have a distinct active and visited state. When setting the hover state of links, be sure to include focus state as well, to help readers using assistive technologies and touch devices.
Use lists to present steps, groups, or sets of information. Give context for the list with a brief introduction. Number lists when the order is important, like when you are describing steps of a process. Do not use numbers when the list's order does not matter.
If one of the list items is a complete sentence, use proper punctuation and capitalization on all of the items. If list items are not complete sentences, do not use punctuation, but do capitalize the first word of each item.
Sometimes a long piece of copy lends itself to a list of related links at the end. Don’t go overboard—4 is usually plenty.
Related articles should appear in a logical order, following the step down/step up rule: The first article should be a step down in complexity from the current article. The second one should be a step up in complexity to a more advanced article.
If you can, avoid repeating links from the body text in related articles.
We write for humans, not machines. We do not use gross SEO techniques like keyword stuffing to bump search results. But we also want to make it easy for people and search engines to find and share our content. Here are some good ways to do this:
Agaric blog posts are written by people from all over the company, not just those with “writer” in their job titles. We love having people who know the most about what they do blog about their work. The person most familiar with the subject is in the best position to convey it, and other Agarics can help with brainstorming and editing as needed.
We publish blog posts that explain the “why” behind the work we do at Agaric. We want to show people that we are an industry leader and we use our blog to tell the stories behind our work and services.
When writing for the blog, follow the style points outlined in the Voice and tone and Grammar and mechanics sections. Here are some more general pointers, too.
If you are writing about data, put the numbers in context. If you are writing about an Agaric client, give the reader plenty of information about the organization’s purpose, workflow, technical needs and results.
Get to the important stuff right away, and don’t bury the kicker. Blog posts should be scannable and easy to digest. Break up your paragraphs into short chunks of three or four sentences, and use subheads. Our users are busy, and we should always keep that in mind.
Agaric is a fun company, and we want our blog to reflect this. Feel free to throw in a joke here and there, or link out to a funny GIF or YouTube video when appropriate. Just do not overdo it or force it.
In Drupal, add keywords that apply to your article. Look through existing posts for common tags. If you are not sure if a word should be a tag, it probably should not be a tag.
Include images in your blog posts when it makes sense. If you’re explaining how to do something, include screenshots to illustrate your point. Make sure to use alt text.
*This section is heavily influenced by Nick Disabato of [Draft](https://draft.nu).*
A case study shows potential clients a named real-world client we have worked with, along with the impact (economic or other) we had on their business or organization, with social proof from one or more members of the client’s team.
### What to enforce upfront
This involves three bits that need to be contractually enforced before starting any engagement:
* The impact must be measurable. We cite a specific number that indicates the impact of our work. No numeric ranges here: only specific, precise numbers.
* Social proof must be present. Get an awesome quotation about the impact of Agaric’s work from the client and publish the case study with their name in it.
* These must be contractually enforced before the engagement begins, because they are always points of contention later.
**The problem.** Explain or enumerate why a client came to Agaric, as well as any unique aspects of their problem. (The more expensive a problem is for a client, the more clearly we can show our impact.)
**Our thinking.** How did we begin approaching the problem? What research did we conduct to address it? What worked and what did not? What did we try?
**The outcome.** What was the measurable impact of our work?
**A quotation.** What did the client say about our work?
**What happened next.** Did the engagement expand in any capacity? Did we do other valuable things for them that were not part of the initial, agreed-upon scope?
**A call to action.** Case studies exist to generate additional leads for the consultancy, so end with a clear next step for the reader to take – one that probably begins with introducing the kind of work we can do for them, and encourages them to apply.
Initiatives are meant to inform our audiences of how our work extends out to the greater world. Clearly convey their purpose, impact and how people can get involved.
Start with the essentials: what, when, where, cost and then follow with more specific details such as information about the people presenting or links to further background information.
This is an opportunity for people’s individuality to come through. Make these personable, highlight people’s passions, expertise and interesting facts that connect them to the reader.
Someone reading technical content is usually looking to answer a specific question. That question might be broad or narrowly-focused, but either way our goal is to provide answers without distraction.
We don’t want to overload a reader with unnecessary information, choices to make, or complex ideas or phrases, when we don’t have to. This is particularly critical when a user may be new and/or frustrated. When relevant, prime the reader with a brief outline of an article’s focus in an introductory paragraph or section, and stick to the topic at hand. Keep sentences, paragraphs, and procedural steps focused and concise.
Before you begin writing a new article, reach out to a subject matter expert (like an engineer, tester, designer, researcher, or technical support advisor) to get as much information as possible. You may only use a small portion of what you learn, but it helps to have more information than you need to decide where to focus your article.
When you are happy with a draft, pass it to another technical writer for peer review. Then show it to a lead technical writer for additional review and revisions. For new content or highly complex content, send last draft to your subject matter expert for final approval.
When writing technical content, follow the style points outlined in the Voice and tone and Grammar and mechanics sections. Here are some more general pointers, too.
When a user clicks the title of an article, they expect to find the answer they want. Do not stray too far from the title or topic at hand. Use links to make related content available. If you find you are getting too far from the intended topic, then you may need to create a separate but related article.
#### Keep headlines and paragraphs short and scannable
Focused users often scan an article for the part that will answer their particular question. Be sure headlines are short, descriptive, and parallel, to facilitate scanning.
Be as clear as possible. Use simple words and phrases, avoid gerunds and hard-to-translate idioms or words, focus on the specific task, limit the number of sentences per paragraph. If you must include edge cases or tangentially related information, set it aside in a Before You Start list or Notes field.
#### Provide context through embedded screenshots and GIFs
Screenshots and GIFs may not be necessary for every article or process, but can be helpful to orient new users. Crop screenshots tightly around the action to focus attention.
Technical content uses organization, capitalization, and other formatting to help convey meaning. Although different articles are organized differently, some formatting tips are consistent throughout all technical content.
Capitalize proper names of Agaric products, features, pages, tools, and team names when directly mentioned. In step-by-step instructions, capitalize and italicize navigation and button labels as they appear in the app.
Group article content with H2s and H3s. Use H2s to organize content by higher-level topics or goals, and use H3s within each section to separate supporting information or tasks.
Only use ordered lists for step-by-step instructions. Separate steps into logical chunks, with no more than 2 related actions per step. When additional explanation or a screenshot is necessary, use a line break inside the list item.
People should be able to keep up with Agaric however they choose, so we should introduce the ability to subscribe to blog posts by e-mail as well as by RSS. But that is different from an e-mail newsletter.
E-mail newsletters use our [voice and tone](#id1) and follow our [grammar and mechanics](grammar-and-mechanics), in addition to these newsletter-specific considerations.
Every email newsletter is made up of the following elements. Make sure they’re all in place before clicking send:
#### From name
This is usually the company or team's name. It identifies the sender in the recipient's inbox.
#### Subject line
Keep your subject line descriptive. There is no perfect length, but some email clients display only the first words. Tell—don't sell—what's inside. Subject lines should be in sentence case. (Note that this is different from a headline, which you may want to include in the campaign itself.)
#### Preheader text
The top line of your e-mail appears beside each subject line in most inboxes. Provide the info readers need when they're deciding if they should open.
#### Body copy
Keep your content concise. Write with a clear purpose, and connect each paragraph to your main idea. Add images when they are helpful.
#### Call to action
Make the next step clear. Whether you are asking people to buy something, read something, share something, or respond to something, offer a clear direction to close your message so readers know what to do next.
#### Footer
All campaigns follow CAN-SPAM rules. Include an unsubscribe link, mailing address, and permission reminder in the footer of each newsletter.
### Consider your perspective
When sending an e-mail newsletter from Agaric, use the third person "we." When sending a newsletter as an individual, use the first person.
### Use a hierarchy
Most readers will be scanning your emails or viewing them on a small screen. Put the most important information first.
### Include a call to action
Make the reader's next step obvious, and close each campaign with a call to action. Link to a blog post, event registration, purchase page, or signup page. You can add a button or include a text link in the closing paragraph.
### Avoid unnecessary links
More than 50 percent of emails are read on a mobile device. Limit links to the most important resources to focus your call to action and prevent errant taps on smaller screens.
### Use alt text
Some email clients disable images by default. Include an alt tag to describe the information in the image for people who are not able to see it.
It is exciting to send to thousands of people at once, but it is doubtful that every subscriber is interested in every topic. Segment your list to find a particular audience that is likely to react.
Once you have selected an audience, adjust the language to fit their needs. For example, people who have attended trainings are more likely to understand and appreciate direct, technical terms.
### Test your campaigns
Use the preview mode to begin, and run an Inbox Inspection to see your newsletter in different email clients. Read your campaign out loud to yourself, then send a test to a coworker for a second look.
## Writing for social media
We use social media to build relationships with Agaric clients and supporters and share all the cool stuff we do. But it also creates lots of chances to say the wrong thing, to put off clients, and to make people think less of us. So we are careful and deliberate in what we post to our social channels. This section lays out how we strike that delicate balance.
Our writing for social media should generally follow the style points outlined in the [Voice and tone](#id1) and [Grammar and mechanics](#id3) sections. Here are some additional pointers.
#### Write concisely, but clearly
Some social media platforms have a character limit; others do not. But for the most part, we keep our social media copy short.
To keep your posts short, simplify your ideas or reduce the amount of information you are sharing—but not by altering the spelling or punctuation of the words themselves. It is fine to use the shorter version of some words, like "info" for "information". But do not use numbers and letters in place of words (no "4" instead of "for" or "u" for "you".
Threads are fine to express more complex ideas or more related information, but ensure each post in the thread stands on its own as a coherent statement.
Do your best to adhere to Agaric style guidelines when you are using our social media channels to correspond with users. Use correct grammar and punctuation—and avoid excessive exclamation points.
When appropriate, you can tag the subject of your post on Twitter or Facebook. But avoid directly tweeting at or otherwise publicly tagging a post subject with messages like, "Hey, we wrote about you!" Do not ask for retweets, likes, or favorites.
* Yes: “We talked with @dinarcon about configuring YAML definition files https://agaric.coop/blog/drupal-migrations-reference-list-configuration-options-yaml-definition-files”
* No: “Hey @mlncn, can you RT this post we wrote about the training you are giving? https://agaric.coop/blog/learn-how-migrate-drupal-8-successfully-nonprofit-technology-pre-conference-day”
Do respond promptly to people who tag us (and are not trolls).
We employ hashtags rarely and deliberately. We may use them to promote an event or connect with users at a conference. Do not use current event or trending hashtags to promote Agaric unless it applies directly to our work (eg: #drupal#freesoftware#netneutrality).
We are always working to make our content more accessible and usable to the widest possible audience. Writing for accessibility goes way beyond making everything on the page available as text. It also affects the way you organize content and guide readers through a page. Depending on the audience and country, there may be laws governing the level of accessibility required. At minimum, an accessible version should be available. Accessibility includes users of all mental and physical capacities, whether situational (broken glasses!) or more permanent.
We write for a diverse audience of readers who all interact with our content in different ways. We aim to make our content accessible to anyone using a screen reader, keyboard navigation, or Braille interface, and to users of all cognitive capabilities.
* Mobile devices with accessibility features are increasingly becoming core communication tools, does this work well on them?
Many of the best practices for writing for accessibility echo those for writing technical content, with the added complexity of markup, syntax, and structure.
* Avoid directional instructions and any language that requires the reader to see the layout or design of the page. Avoiding this is helpful for many reasons, including having the instructions still make sense after layout changes on mobile.
Use a skip navigation link so that screen reader or keyboard-only users can avoid listening to or tabbing through many navigation elements before getting to the main content. Drupal provides this by default.
Headers should always be nested and consecutive. Never skip a header level for styling reasons. To help group sections, be sure the page title is H1, top-level sections are H2s, and subsequent inside those are H3 and beyond. Avoid excessive nesting.
Put the most important information first. Place similar topics in the same paragraph, and clearly separate different topics with headings.
Starting with a simple outline that includes key messages can help you create a hierarchy and organize your ideas in a logical way. This improves scannability and encourages better understanding.
Make true lists instead of using a paragraph or line breaks.
Label inputs with clear names, and use appropriate tags. Think carefully about what fields are necessary, and especially which ones you mark as required. Label required fields clearly. The shorter the form, the better.
Write short sentences and use familiar words. Avoid jargon and slang. If you need to use an abbreviation or acronym that people may not understand, explain what it means on first reference.
The alt tag is the most basic form of image description, and it should be included on all images. The language will depend on the purpose of the image:
* If the image is serving a specific function, describe what is inside the image in detail. People who do not see the image should come away with the same information as if they had.
Aim for high contrast between your font and background colors. Tools in the resources section should help with picking accessible colors.
Images should not be the only method of communication, because images may not load or may not be seen. Avoid using images when the same information could be communicated in writing.
Agaric serves users in several countries and territories, not just the United States. As our user base grows, it becomes more and more important that our content is accessible to people around the world.
We call the process of writing copy for translation "internationalization." This section will address things you can do to help international audiences, including translators, better comprehend your text.
We try to write all of our content in standard, straightforward English that can be understood by users with limited English proficiency. It is much easier for a translator to clearly communicate ideas written in straightforward, uncomplicated sentences.
Use positive words when talking about positive situations. For example, because a question like "Don't you think she did a great job?" begins with a negative word, a non-native English speaker may interpret its implication as negative. A better version would be "She did a great job, yes?"
When writing for international audiences, we generally follow what is outlined in the Voice and tone and Grammar and mechanics sections. But in this section more than others, some style points contradict what is stated elsewhere in the guide. If you are writing something to be translated, the guidelines in this section should take precedence.
Agaric's voice is conversational and informal. However, in some cultures, informal text may be considered offensive. Check with your translator to see if this is the case for the particular language you're writing for.
Some languages have a clearer distinction between a formal or informal tone. (For example, in Spanish, it is possible to write informally where tú = you or formally where usted = you.)
When writing text that will be translated, be careful about making references to things of local or regional importance. These may not be recognizable to readers outside the US.
Keep your copy brief, but do n’t sacrifice clarity for brevity. You may need to repeat or add words to make the meaning of your sentences clear to a translator.
Many words, parts of speech, and grammar mechanics we don’t think twice about have the potential to cause confusion for translators and non-native English speakers. Here are some of the big trouble spots to avoid.
Yes: Many believe that making functionality changes directly to a live site is OK. Such action can actually cause a site to break. Making functionality changes directly to a live site is not recommended.
In English, many different types of words end in -ing: nouns, adjectives, progressive verbs, etc. But a translator who is a non-native English speaker may not be able to recognize the distinctions and may try to translate them all in the same way.
Because of this, we want to avoid -ing words when possible. One exception to this rule is words like “graphing calculator” and “riding lawnmower,” where the -ing word is part of a noun's name.
* Synonyms, generally. Do not use a lot of different words for the same thing in a single piece of writing. Instead of mixing it up with “campaign,” “newsletter,” “bulletin,” etc., pick one term and stick with it.
“Has” or “have” plus past participle (could confuse the relationship between subject and object)
Yes: The folder contains sent campaigns.
No: The folder has sent campaigns.
#### Numbers
**Measurements**
When writing for an international audience, use the metric system. Spell out all units and avoid abbreviation.
**Currency**
Many countries call their currency "the dollar," but the value is going to differ between countries. The US dollar is not the same as the Canadian dollar, for example. So it’s important to specify.
Originally adapted from [Mailchimp's content style guide](https://styleguide.mailchimp.com/), Agaric's content style guide is likewise available under a [Creative Commons Attribution-NonCommercial 4.0 International license](http://creativecommons.org/licenses/by-nc/4.0/).
