Language and style
People usually read technical documentation because they want something up and running quickly. Write simpler, more concise sentences.
Split the content into smaller paragraphs to improve readability.
This will also eliminate the need for using
|br| and help us translate content faster.
Any paragraph over 6 sentences is large.
Consider your audience’s level. A getting started guide should be written in simpler terms than an advanced internals description.
If you choose to use metaphors to clarify a concept, make sure they are relatable for an international audience of IT professionals.
Only use the pronoun «we» in entry-level texts like getting started guides. In other cases, avoid using «we», because it is unclear who that is exactly. Consider how Gentoo does it.
Say exactly one thing in a sentence. If you want to define or clarify something, do it in a separate sentence. Simple sentences are easier to read, understand and translate.
|Dogs (I have three of them) are my favorite animals. Their names are Ace, Bingo and Charm; Charm is the youngest one.||Dogs are my favorite animals. I have three of them. Their names are Ace, Bingo and Charm. Charm is the youngest one.|
|memtx (in-memory движок базы данных) используется по умолчанию, который был первым.||memtx is an in-memory storage engine. It is the default and was the first to arrive.|
|The replica set from where the bucket is being migrated is called the source; the target replica set where the bucket is being migrated to is called the destination.||The replica set from where the bucket is being migrated is called the source. The target replica set where the bucket is being migrated to is called the destination.|
It’s best if examples immediately follow the concept they illustrate. The readers wouldn’t want to look for the examples in a different part of the article.
Lists and tables help split heavy content into manageable chunks.
To make tables maintainable and easy to translate,
list-table directive, as described in the Tarantool
table markup reference.
Translators find it hard to work with content «drawn» with ASCII characters, because it requires adjusting the number of spaces and manually counting characters.
Format large code fragments using the
code-block directive, indicating the language.
shorter code snippets, make sure that only code goes in the backticks.
Non-code shouldn’t be formatted as code, because this confuses users (and translators, too).
Check our guidelines on
writing about code.
For more about formatting, check out the Tarantool markup reference.
We say «instance» rather than «server» to refer to a Tarantool
server instance. This keeps the manual terminology consistent with names like
/etc/tarantool/instances.enabled in the Tarantool environment.
Wrong usage: «Replication allows multiple Tarantool servers to work with copies of the same database.»
Correct usage: «Replication allows multiple Tarantool instances to work with copies of the same database.»
Don’t use the following contractions:
- «i.e.»—from the Latin «id est». Use «that is» or «which means» instead.
- «e.g.»—from the Latin «exempli gratia». Use «for example» or «such as» instead.
Many people, especially non-native English speakers, aren’t familiar with the «i.e.» and «e.g.» contractions or don’t know the difference between them. For this reason, it’s best to avoid using them.
The word «Tarantool» is capitalized because it’s a product name. The only context where it can start with a lowercase «t» is code. Learn more about code formatting in Tarantool documentation.
Use the US English spelling.
Consider checking spelling, grammar, and punctuation with special tools.
Special symbols like dashes, quotation marks, and apostrophes look the same across all Tarantool documentation in a single language. This is because the documentation builder renders specific character sequences in the source into correct typographic characters.
Type three hyphens (
---) to insert an em dash (—)
and two hyphens (
--) for an en dash (–).
The following rules apply:
- The longer em dash
---is used to separate extra information or mark a break in a sentence.
- The shorter en dash
--is used to mark ranges (for example, 4–16 GB or Dover–Calais crossing).
Don’t use a single hyphen as a dash. Don’t add spaces on either side of a dash.
When indicating a range like
code element 1–
code element 2, escape the series of hyphens using
character-level inline markup.
Otherwise, the RST interpreter will perceive the dash as part of the RST syntax:
The following recommendations are for the English language only. You can find similar guidelines for the Russian language in the external reference for Russian proofreaders.
There are two kinds of lists:
- Where each item forms a complete sentence.
- Where each item is a phrase of three or less words or a term.
In the former case, start each item with a capital letter and end with a period. In the latter case, start it with a lowercase letter and add no ending punctuation (no period, no comma, no semicolon).
A list should be formatted uniformly: choose the first or second rule for all items in a list.
The above rules are adapted from the Microsoft style guide.
The sentence preceding a list can end either with a semicolon or a period.
Don’t add redundant conjunctions like «and»/»or» before the last list item.
General English punctuation rules still apply for text in lists.
For the text in cells, use periods or other end punctuation only if the cells contain complete sentences or a mixture of fragments and sentences. (This is also a Microsoft guideline for the English language.)
Besides, make sure that your table punctuation is consistent—either all similar list/table items end with a period or they all don’t. In the example below, all items in the second column don’t have ending punctuation. Meanwhile, all items in the fourth column end with a period, because they are a mix of fragments and sentences:
To learn more about table formatting, check the table markup reference.