Content standardization
Introduction
This guideline aims to maintain a consistent documentation style and help contributors standardize their content so that it seamlessly integrates into the documentation.
Text preferences
Use American English
For words that have multiple spellings, use American English over British English.
Examples:
- "decentralized" over "decentralised"
- "color" over "colour"
- "analyze" over "analyse"
Use present tense
Use present tense to describe general behavior, current functionality, and step-by-step instructions. This makes documentation clear and easy to follow.
Examples:
- This guideline provides an overview of the contribution process.
- The system checks the file format and shows an error if it is invalid.
Avoid future or past tense for immediate or typical actions.
Avoid:
- The system will check the file format.
- The user clicked the button.
When to use the future or past tenses
Present tense is standard, but future and past tenses are allowed in specific cases.
Future tense: for actions that happen later, after a condition or delay.
Examples:
- After setup, the system will send a confirmation email.
- If payment fails, the user will get a notification.
Avoid the future tense for immediate behavior or unreleased features. Also, avoid would.
Avoid:
- The system will check the file format.
- The API would return an error.
Past tense: for describing past events like changelogs or logs.
Examples:
- Version 2.1 fixed a validation issue.
- The user submitted the form at 2 pm and got a 500 error.
Avoid past tense in general documentation — it can imply outdated info.
Avoid:
- The system checked the user’s location.
- The user clicked the button.
Use active voice
Sentences using active voice are more concise and efficient, making your writing more engaging and easier to comprehend.
Active voice sentence: An actor acts on a target
"The smart contract processed a message."
Passive voice sentence: A target acts on an actor
"The message was processed by the smart contract."
This isn't an easy one, especially for non-native English speakers. If you aren't sure, don't worry. We'll help with any of these.
Grammar
This documentation uses cspell to correct grammar during development.
The cspell
will check the spelling and automatically suggest corrections in case of mistakes before creating a new commit. Feel free to add specific words to the cspell.json config and include them in the verification dictionary.
Date format
Use the "Mon D, YYYY" format. This approach is standard for American readers, spells out the month (or uses a three-letter abbreviation), and minimizes confusion with day–month ordering.
Preferred format:
- Nov 2, 2023
- Feb 11, 2023
Incorrect format:
- 2-Nov-2023
- 11/2/2023
- 2/11/2023
Adhering to these guidelines creates a unified approach to presenting dates, fostering clarity and comprehension throughout the TON documentation.
Use of emojis and icons
In the Documentation section:
- Avoid using emojis and decorative icons.
- Technical documentation should be clear, professional, and distraction-free.
- Use only standard formatting elements like headings, lists, and code blocks.
In the Guidelines section:
- Emojis and icons are allowed to make content more engaging and friendly.
- Use them purposefully and consistently, preferring functional icons such as:
✅ Success, ⚠️ Warning, ❌ Error.
- Always use icons with supporting text — don’t rely on icons alone to convey meaning.
- Avoid overly decorative or emotional emojis that don’t add meaning.
- When in doubt, skip the icon. Clarity, consistency, and neutrality come first.
Link preferences
Linking to internal pages
When linking to another page on TON documentation, use the relative path over the absolute path.
Correct link:
Read more about [smart contracts](/v3/documentation/smart-contracts/overview/)
Incorrect link:
Read more about [smart contracts](https://docs.ton.org/v3/documentation/smart-contracts/overview)
Don't hard-code the language path (for example, /mandarin/
) in any links. This maintains consistent capability across different language versions of the site.
Correct link:
Read more about [smart contracts](/v3/documentation/smart-contracts/overview/)
Incorrect link:
Read more about [smart contracts](/mandarin/v3/documentation/smart-contracts/overview)
Set a trailing slash to all links. This approach keeps links consistent and avoids redirects, which hurts site performance.
Correct link:
Read more about [smart contracts](/v3/documentation/smart-contracts/overview/)
Incorrect link:
Read more about [smart contracts](/v3/documentation/smart-contracts/overview)
Article authors
When citing articles by a specific author or organization, use the article's name as a link, followed by a dash and the author's name italicized.
Correct description:
- [How to shard your TON smart contract and why](https://blog.ton.org/how-to-shard-your-ton-smart-contract-and-why-studying-the-anatomy-of-tons-jettons) — _Tal Kol_
- [TON Teleport BTC Whitepaper](https://tgbtc.gitbook.io/docs/whitepaper/abstract) – _RSquad Blockchain Lab_
Incorrect description:
- [How to shard your TON smart contract and why](https://blog.ton.org/how-to-shard-your-ton-smart-contract-and-why-studying-the-anatomy-of-tons-jettons)
- [TON Teleport BTC Whitepaper](https://tgbtc.gitbook.io/docs/whitepaper/abstract) by RSquad Blockchain Lab
See also links section
Include related resources on your page in an H2 section titled ## See also
.
This section guides readers to additional materials and supports a cohesive developer journey.
Example:
## See also
- [Style guide](/v3/contribute/style-guide/)
- [Typography](/v3/contribute/typography/)
- [Localization program](/v3/contribute/localization-program/overview/)