diff --git a/_includes/writing/language.html b/_includes/writing/language.html new file mode 100644 index 0000000..cb4dfe4 --- /dev/null +++ b/_includes/writing/language.html @@ -0,0 +1,212 @@ +
+Make sure your writing is clear, consistent, and localizable by using the following conventions: +
+Don't use internal abbreviations in customer-facing copy.
+Don't use apostrophes for plural abbreviations.
+Don't use i.e. or e.g.; they are not localization-friendly.
+Use bold text to draw the reader's eye to key phrases and statements in your email and web content. For product copy or help articles, use bold for static UI elements like menu items, buttons, screen headings, and anything else you want to call attention to.
+If you need to bold an element but the UI doesn't support it, for example, in a dialog header or a UI message, you can use italics instead.
+Use italics for fields that might change, like a page name. See italics for more guidelines.
+Use sentence case in all titles, headings, menu items, labels, and buttons.
+Use colons to introduce a bulleted list or series of steps. Don't use colons at the end of headings.
+In keeping with our more conversational, friendly voice, use contractions.
+Quote with quotes, not italics.
+Avoid exclamation marks! They should only be used for exciting or new things! At the most, there should only be one exclamation mark per page!
+When possible, avoid gendered pronouns. If you can't, then they or their is preferable to his or her or he or she.
+Not sure if it's coworker or co-worker? See the Word List (coming soon!)
+Use different verbs depending on what you're telling the user to do:
+Yes:
Use italics for emphasis, citations, or defining a term. You can also use it for UI elements that might change, like a field name or user input. +
+You can also use italics in places where you would normally use bold but the UI doesn't support it. For example, in a dialog header or UI message. +
+Don't use italics if the item is also a hyperlink. +
+See bold for more information about how to format UI elements. +
+Use lists to draw the reader's eye and make items easier to scan and follow. Use proper punctuation in your items if they are complete sentences. Try to limit lists to six items or fewer. If you need more items, see if you can split the list into multiple lists.
+Use bulleted lists for options, or a list where the order of the items doesn't matter. Phrase each item in a parallel way. If the bullets complete the introductory sentence, start the fragments with lowercase and skip the periods.
+Yes:
+Due to security concerns, all employees are now required to:
+No:
+Due to security concerns, all employees are now required to follow the regulations below:
+Use numbered lists for tasks, or lists where the order of the items matters. Unlike with bulleted lists, always capitalize the first word in each item and end the item with a period.
+You don't need to create a list for tasks that have 2 or fewer steps.
+To add a new user macro:
+Use monospaced font for names of a file or directory. It is mostly used in administrator and developer docs. For example:
+The location of the Home directory is stored in a configuration file called confluence-init.properties
, which is located in the confluence/WEB-INF/classes
directory in your Confluence Installation directory.
Write out numbers one through ten. After ten, you can use 11, 12, 108, and so on.
+Can't remember if it's filesystem or file system? Check out the Word List (coming soon!)
+Use the Oxford or serial comma to offset the final item in a list.
+Use only one space after a period. Avoid periods in headers, titles, tooltips, field descriptions, and menu names. Use to complete description text in the product, messages, and notifications. Don't use them in a bulleted list unless the list item is a complete sentence.
+Use ’s to show possession, even if the word ends in s.
+In most cases, second person is best. It fits Atlassian's casual, conversational tone to refer to the reader directly. Exceptions can be made for specific types of writing, such as whitepapers and press releases.
+Not sure whether it's My projects or Your projects? It can be fuzzy, so sometimes, we aren't either! For best results, avoid using mine, my, or your in UI copy.
+If you need to use mine, my, or your, the rule of thumb is to think of the UI as a conversation between the system and the user.
+If the system is presenting information to the user, such as in a dialog box, then your is more appropriate, because it's like saying "Here are your things", or "What would you like to do?"
If the user is performing an action, such as clicking a button or a link, then mine/my is more appropriate, because it's like saying "Show me my stuff!".
Use double quotes (") for a direct quote. For UI elements, page titles, and other objects, use bold text or italics as appropriate.
+Because we write in US English, punctuation goes inside the quotation marks.
+Five great guidelines for clear, concise writing, courtesy of George Orwell:
+Use sentence case for . Don't use bold, italics, or standard punctuation in headings. It's ok to use question marks and exclamation points if they fit the criteria for those two marvelous pieces of punctuation.
+The use of articles (the, a, an) in headings depends on whether the message is conversational or action-based microcopy. Avoid articles in buttons and labels. +
+In more conversational sections of the interface, like Home cards, marketing copy, and empty states, use articles. It makes the language more approachable and helps understanding when introducing new, complex concepts.
+Phrase documentation H1s with an action verb. Don't use gerunds or questions.
+Go to More ••• > Link issues.
+We write with US English spelling and punctuation, but our Australian roots are still part of our personality. Communications directly from native Aussies can use the Queen's English – e.g., colour, optimise, theatre.
+For example, Aussie PMs writing JAC comments to customers can use Australian English. Developers should code in US English.
+We follow the AP Style Guide.
+Our personality sets the tone for interactions within I2P platforms. It reflects a wide variety of values from different backgrounds associated with I2P. It's vital that these values are recognizable in the external-facing software and mediums we build and maintain.
diff --git a/_layouts/writing.html b/_layouts/writing.html index fce4f0d..bdd5ed0 100644 --- a/_layouts/writing.html +++ b/_layouts/writing.html @@ -14,9 +14,10 @@