Adapt content from Status style guide

manual/3-validate-the-design/writing-rules/style-the-content/README.md

@@ -0,0 +1,5 @@
+This section describes the most common style elements and conventions in the Status user documentation. The goal is to simplify the writer's workflow using unambiguous guidelines that are easy to remember and follow.
+
+For most of our style conventions, you can find both the *correct* and *incorrect* use examples in this guide. In many cases, the *incorrect* examples are valid and commonly used sentences in English. They're incorrect only in the context of this style guide and the Status technical documentation.
+
+We prioritize simplicity over comprehensiveness. If you can't find a particular style convention, use the [Microsoft Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/). If you think a style convention is missing, you can contribute to this guide.

manual/3-validate-the-design/writing-rules/style-the-content/admonitions.md

@@ -0,0 +1,32 @@
+# Admonitions
+
+- Logos documentation uses three different types of callouts:
+
+    | Callout | Description |
+    |:-----------|:------------|
+    | **Tip**    | Helpful information that is not required for the task, such as a keyboard shortcut. |
+    | **Note**   | Relevant information for completing the task, but does not affect the user's actions. |
+    | **Important**| Information that may impact the user's actions or decisions about completing the task. |
+    | **Caution**| Information that may impact the user's actions or decisions about completing the task. |
+
+- Don't use *warning*, *error*, *danger*, *bug*, *important*, or *notes*.
+- In procedural steps, place the callout after the procedure. If you need an admonition for a specific step, write the admonition after the step.
+- For other content, add the callout after the relevant information.
+
+### Admonition types
+
+> ✨ **Tip:**
+>
+> The blockchain records transactions in blocks, hence the term "blockchain".
+
+> 📒 **Note:**
+>
+> The blockchain records transactions in blocks, hence the term "blockchain".
+
+> 🖐 **Important:**
+>
+> If you choose the CLI installation option, you must first export the API key as an environment variable.
+
+> ⚠️ **Caution:** 
+>
+> The blockchain records transactions in blocks, hence the term "blockchain".

manual/3-validate-the-design/writing-rules/style-the-content/bullet-lists.md

@@ -0,0 +1,30 @@
+# Bullet lists
+
+- Don't use a bullet list for actions that users should complete in an orderly manner; use numbered lists in procedures.
+- Use a bullet list to improve the readability of sentences or paragraphs where you list or describe three or more items.
+
+    | Usage      | Example                                                                                           |
+    |:------------|:---------------------------------------------------------------------------------------------------|
+    | **Correct**| You need a machine running Ubuntu Linux with the following minimum requirements:<br>- 4 GB memory<br>- 2 TB SSD<br>- Linux 64-bit |
+    | Incorrect  | You need a machine running Ubuntu Linux with the following minimum requirements: 4 GB memory, 2 TB SSD, and Linux 64-bit. |
+    | Incorrect  | You need a machine with 4 GB of memory, a 2 TB SSD, and a 64-bit Ubuntu Linux operating system.  |
+
+- Use a colon (:) before the bullet list items.
+- Use periods at the end of each sentence in a bullet list for [punctuation](./punctuation-and-symbols.md). Using periods on a bullet list can be tricky. Use the following guidelines:
+    - When the list items are complete sentences, use a period at the end of each sentence.
+    - Don't use a period when the list items are not complete sentences or sentences with three words or less.
+    - In a list with elements of more and less than three words mixed, don't use a period.
+    - If one item in a column is a complete sentence, all items in that column should end with a period, even if they are a single word.
+<!--
+- Don't use colons after each item on a list; type the item definition on a new line. Here are some examples of using punctuation on a list:
+
+    | Usage      | Example                                                                 |
+    |:------------|:-------------------------------------------------------------------------|
+    | **Correct** | - **Dependency graph**<br>  A repository graph that shows the packages and projects that the repository depends on.<br>- **Dependents graph**<br>  A repository graph that shows the packages, projects, and repositories that depend on a public repository. |
+    | Incorrect  | - **Dependency graph**:<br>  A repository graph that shows the packages and projects that the repository depends on.<br>- **Dependents graph**:<br>  A repository graph that shows the packages, projects, and repositories that depend on a public repository. |
+    | Incorrect  | - **Dependency graph**: A repository graph that shows the packages and projects that the repository depends on.<br>- **Dependents graph**: A repository graph that shows the packages, projects, and repositories that depend on a public repository. |
+-->
+
+> ✨ **Tip:**
+>
+> When you need to describe each element on a list and you have more than three elements, consider using a table instead.

manual/3-validate-the-design/writing-rules/style-the-content/capitalization.md

@@ -0,0 +1,19 @@
+# Capitalization
+
+- Use sentence-style capitalization, including titles. That means everything is lowercase except the first word, proper nouns, like the Status product names.
+
+    | Usage       | Example                       |
+    |:------------|:------------------------------|
+    | **Correct** | Configure system admin access |
+    | Incorrect   | Configure System Admin Access |
+
+- Don't capitalize words after colons, except when these words are proper nouns, acronyms, or bullet list items.
+
+    | Usage       | Example                                                                                                                                         |
+    |:------------|:------------------------------------------------------------------------------------------------------------------------------------------------|
+    | **Correct** | You can run the command-line application in several ways: using the binary, using Docker, or running as a service in Linux.                     |
+    | Incorrect   | You can run the command-line application in several ways: Using the binary, using Docker, or running as a service in Linux.                     |
+    | **Correct** | You can run the command-line application in several ways:<br>- Use the binary.<br>- Use Docker.<br>- Run as a service in Linux.                 |
+    | Incorrect   | You can run the command-line application in several ways:<br>- use the binary<br>- use Docker<br>- run as a service in Linux.                   |
+    | **Correct** | Many digital currencies use the ERC-20 standard: Status (STN), Basic Attention Token (BAT), MakerDAO (DAI), and others.                         |
+

manual/3-validate-the-design/writing-rules/style-the-content/checkbox-lists.md

@@ -0,0 +1,6 @@
+# Checkbox lists
+
+Use a [numbered list](./numbered-lists.md) for steps that the user can finish in one continuous session. Use a checkbox list for items that may be started, paused, and resumed later (for example, when you must wait days or weeks before the next action).
+
+  ✅ Item 1<br>✅ Item 2<br>✅ Item 3
+

manual/3-validate-the-design/writing-rules/style-the-content/global-language.md

@@ -0,0 +1,14 @@
+# Global language
+
+- Don't use idioms, colloquial expressions, and culture-specific references. When writing examples to clarify a feature or concept, don't use historical references, brand names, social or political events, or any other topic that might be controversial or meaningless for a global audience.
+- Observe the style rules for [numbers, date and time, currencies and units of measure](./14-numbers-date-and-time-currencies-and-units-of-measure.md).
+- Use left and right carefully. Localized products in left-to-right (LTR) languages may have labels on the opposite side. Refer the reader to the specific UI element on the screen instead.
+- Don't use pronouns like *Who*, *Whose*, or *Its*; replace the pronoun with the noun.
+- Avoid using *(s)* for plural forms.
+
+    | Usage       | Example                                                       |
+    |:------------|:--------------------------------------------------------------|
+    | **Correct** | Every file upload requires special permissions.               |
+    | Incorrect   | The file(s) upload requires special permissions.              |
+    | **Correct** | This option returns each token on your list alphabetically.   |
+    | Incorrect   | This option returns the token(s) on your list alphabetically. |

manual/3-validate-the-design/writing-rules/style-the-content/links.md

@@ -0,0 +1,29 @@
+# Links
+
+Use links to other articles in the Logos documentation, but don't abuse links. For example, avoid making the topic resemble a Wikipedia article with a link in every sentence.
+
+- Limit the links for sources outside the Logos documentation.
+- Don't use links in procedural steps, except when you link to a subtask in the same article.
+- In general, write the link without using the URL. If you must use the URL, omit the `https://` and the `www` parts of the URL (if the website allows this).
+- Don't hide the linked content using the words _here_ or _this_. Instead, write out the content you link.
+
+    | Usage       | Example                       |
+    |:------------|:------------------------------|
+    | **Correct** | For more details about tokens, check out **Understand Status tokens**. |
+    | Incorrect   | For more details about tokens, check out **this** article. |
+
+- When pointing the user to external sources, start you sentence with *For more details*.
+
+    | Usage       | Example                       |
+    |:------------|:------------------------------|
+    | **Correct** | For more details about tokens, check out **Understand Status tokens**. |
+    | **Correct** | For more details, check out **Understand Status tokens**. |
+    | Incorrect   | To learn more about tokens, check out **this** article. |
+
+- For links outside of the Logos documentation site, use the ↗ arrow symbol at the end of the link description. If the arrow symbol is at the end of a sentence, write a period after the symbol. 
+
+    | Usage       | Example                       |
+    |:------------|:------------------------------|
+    | **Correct** | See [status.app/features ↗](https://status.app/features). |
+    | Incorrect | [https://status.app/features ↗](https://status.app/features).|
+    | Incorrect   | See 'Safely open apps on your Mac' at [https://support.apple.com/en-us/HT202491](https://support.apple.com/en-us/HT202491). |

manual/3-validate-the-design/writing-rules/style-the-content/modal-verbs.md

@@ -0,0 +1,22 @@
+# Modal verbs
+
+Modal verbs are auxiliary verbs that modify the meaning of the main verb in a sentence. Modal verbs can be problematic in technical communication:
+
+- Some modal verbs create a sense of uncertainty in readers.
+- Using modal verbs like *should* or *must* can make your tone sound bossy and less helpful. In many cases, using the imperative is a better option. For example:
+
+    | Tone          | Example                                      |
+    |:--------------|:---------------------------------------------|
+    | **Assertive** | Save your seed phrase in a secure location.  |
+    | Bossy         | You should save your seed phrase in a secure location. |
+
+- Use this reference for the most frequent modal verbs:
+
+    | Modal verb           | Usage                                                                                                                                           |
+    |:---------------------|:------------------------------------------------------------------------------------------------------------------------------------------------|
+    | **can**              | Use to express the possibility for the user to do something, such as introducing a new concept or functionality.<br>Example: You can create multiple wallets for different purposes. |
+    | **should**           | If possible, use the imperative form of the verb instead.                                                                                       |
+    | **have to**          | Use *must* instead.                                                                                                                             |
+    | **must**             | Use very selectively and only when it is strictly necessary for the user to do something to avoid data loss, data corruption, or unintended information disclosure. |
+    | **could, would, might** | Don't use.                                                                                                                                   |
+

manual/3-validate-the-design/writing-rules/style-the-content/numbered-lists.md

@@ -0,0 +1,10 @@
+# Numbered lists
+
+- When reading instructions, users understand numbered lists as actions to complete orderly. Because of this, limit the numbered lists to procedural instructions in procedure topics.
+- If you must use a numbered list outside of a procedure, use the same rules described for bullet lists.
+- Use "1." for all items in a Markdown numbered list. This ensures the Markdown list renders correctly and simplifies reordering.
+
+    | Usage     | Example |
+    |:----------|:--------|
+    | **Correct** | 1. Open the web page in your browser.<br>1. Click the "Sign In" button.<br>1. Enter your credentials. |
+    | Incorrect   | 1. Open the web page in your browser.<br>2. Click the "Sign In" button.<br>3. Enter your credentials.  |

manual/3-validate-the-design/writing-rules/style-the-content/numbers-date-and-time-currencies-and-units-of-measure.md

@@ -0,0 +1,62 @@
+# Numbers, date and time, currencies, and units of measure
+
+- In body text, always use numerals (for example, 2, 5, 21). Don't spell out whole numbers (two, five, twenty-one).
+- For decimals, always begin with a zero before the decimal point and use a dot (.) as the decimal separator. Do not spell out decimals.
+
+    | Usage     | Example |
+    |:----------|:--------|
+    | **Correct** | 20.23   |
+    | **Correct** | 0.13    |
+    | Incorrect   | 0,13    |
+
+- When writing in English, use a space as the thousand separator and a period (.) as the decimal separator to improve readability. For languages other than English, use the commonly accepted rule in the country or a comma if a common practice is unknown or controversial.
+
+> 📒 **Note:** 
+>
+> There isn't a common notation for thousand and decimal separators and notation varies among different countries. In the United States, the decimal separator is a period (.) and the thousands separator is a comma (,). In Germany, the decimal separator is a comma (,) and the thousands separator is a period (.). In Sweden, the thousands separator is a space.
+
+    | Usage     | Example |
+    |:----------|:--------|
+    | **Correct** | 2 500     |
+    | Incorrect   | 2500      |
+    | **Correct** | 12 500    |
+    | Incorrect   | 12.500    |
+    | **Correct** | 2 500.46  |
+    | Incorrect   | 2 500,46  |
+    | **Correct** | 118 000   |
+    | Incorrect   | 118,000   |
+    | **Correct** | 118 000 000  |
+    | Incorrect   | 118'000'000  |
+
+- Don't use *rd.* or *th.* to express dates or indicate the order of things.
+
+    | Usage     | Example |
+    |:----------|:--------|
+    | **Correct** | Choose the options in rows 3 and 5.     |
+    | Incorrect   | Choose the options in the 3rd and the 5th rows.      |
+
+- Different countries use different ways of writing days as numerals. Write out the date to avoid confusion.
+
+    | Usage     | Example |
+    |:----------|:--------|
+    | **Correct** | The latest version was released on May 6, 2024.     |
+    | Incorrect   | The latest version was released on 05/06/24.      |
+    | Incorrect   | The latest version was released on the 6th of May, 2024.      |
+
+- For writing decades, use two-digit numbers with an apostrophe (') before and the *s* letter after the number (for example, *'90s*).
+- To describe a time, use the 12-hour clock with lowercase a.m./p.m. notation after the time. Don't write out the time.
+
+    | Usage       | Example              |
+    |:------------|:---------------------|
+    | **Correct** | 1 p.m.               |
+    | Incorrect   | 13 h.                |
+    | Incorrect   | 1pm                  |
+    | Incorrect   | 1 PM                 |
+    | **Correct** | 8:30 p.m.            |
+    | Incorrect   | half past eight      |
+
+- Use the [UTC time standard](https://en.wikipedia.org/wiki/Coordinated_Universal_Time) when writing for a global audience.
+- For cryptocurrencies, NFTs, or DeFi tokens, use the symbol described on their website or use the symbol from [CoinMarketCap](https://coinmarketcap.com/) or [CoinGecko](https://www.coingecko.com/).
+- For crypto amounts, place the symbol after the number.
+- For fiat currencies, use the [ISO4217](https://www.iso.org/iso-4217-currency-codes.html) currency symbol after the amount. If you're using fiat to illustrate a concept, use [the most popular currencies](https://en.wikipedia.org/wiki/Template:Most_traded_currencies) like the US dollar (USD), Euro (EUR), or Japanese yen (JPY).
+- For units of measure, use the [metric system](https://en.wikipedia.org/wiki/Metric_system) and, if necessary, include the [imperial units](https://en.wikipedia.org/wiki/Imperial_and_US_customary_measurement_systems#Comparison_of_imperial_and_US_customary_systems) conversion in parentheses immediately after.