Files
obsidian-livesync/docs/terms.md
T
vorotamoroz 2461d37ead Document the implemented Replicator architecture
- mark capability and lifecycle ADRs as accepted
- add lifecycle, fencing, and provider-extension guidance
- split project terminology into a dedicated glossary
2026-09-03 06:42:34 +00:00

2.5 KiB

date, commonlib-version, self-hosted-livesync-version, status
date commonlib-version self-hosted-livesync-version status
2026-09-03 0.1.21 1.0.24 accepted

Notes on Terminology, Spelling, Vocabulary Conventions

Spelling and Vocabulary conventions

All guidelines and conventions listed below are disclosed and maintained solely for the sake of documentation consistency.

  1. Almost all of the English words are written in British English. This convention originated from the author's personal preference.

    • Traditional Spelling (Trad-spelling): We prefer traditional British English spellings. In particular, we use -ise and -isation suffixes rather than the Oxford spelling -ize and -ization (for example, 'initialisation', 'synchronisation', and 'organisation').
    • Oxford Comma: We use the serial (Oxford) comma to separate items in lists of three or more (for example, 'settings, snippets, and themes' instead of 'settings, snippets and themes').
    • Logical Punctuation: We place punctuation marks (such as commas and full stops) outside quotation marks, unless the punctuation mark is part of the quoted text itself. For example, we write 'dialogue', not 'dialogue,'.
    • BBC News Styleguide: If in wonder, the BBC News Styleguide may be useful as a reference.
  2. Idiomatic terms, such as those used in HTML, CSS, and JavaScript, are usually aligned with the language used in the technology. For example, "color" instead of "colour", "program" instead of "programme", etc. Especially, terms which are used for attributes, properties, and methods are notable.

  3. We use dialogue in documentation for consistency. While dialog may appear in source code, particularly in class names, method names, and attributes (following technical conventions in No. 2), we consistently use dialogue for user-facing messages and general documentation text. This approach balances No. 1 with No. 2.

  4. Contractions are not used. For example, "do not" instead of "don't", "cannot" instead of "can't", etc., especially 'd.

    • We may encounter difficulties with tenses.
  5. However, try using affirmative forms, Discard instead of Do not keep, Continue instead of Do not stop, etc.

    • Some languages, such as Japanese, have a different meaning for yes and no between affirmative and negative questions.
  6. Single quotation marks (') are preferred over double quotation marks (") in general documentation text, unless the context requires double quotes (for example, inside JSON code blocks).

Terminology

Project-specific meanings are defined separately in the Project glossary.