Skip to content

Writing Style

Common Rules

  • Use American English.
  • Keep text short and to the point.
  • Capitalize titles. Entity names are not titles.
    • Do not capitalize mesh, object, vertex group, etc.
    • Not capitalizing entity names is an arguable guideline, but avoids many fuzzy cases.
  • Do not use abbreviations like verts, VGroups, loc, or rot, fac. Instead, use plain words like vertices, vertex groups, location, rotation, factor.
  • Do not use English contractions like aren’t, can’t, etc. It's preferred to keep full spelling, are not or cannot are not that much longer, and it helps keeping consistent styling over the whole UI.
  • “Channel” identifiers, like X, Y, Z, R, G, B, etc. are always capitalized.

  • Do not use implementation specific language.

    Examples

    • Instead of ID, use data-block.
    • Do not use terms like flag, string, RNA, DNA.

  • Don't use pronouns, such as you. This sounds like an accusation towards the user.

    Example

    Don't: Your mesh is very dense
    Do: The mesh is very dense

  • Use the ampersand (&) in labels, but and in text (e.g. in tooltip descriptions).
  • Text should generally not contain code snippets, or involved details (e.g. troubleshooting, corner cases that might not work, etc.).

Formatting with new lines (\n) and bullet points (\u2022) is fine.

UI Labels

  • Must use English MLA title case (see this overview, also #79589).

    Examples

    • Like in This Example
    • Set Offset from Cursor
    • Alexander and the Terrible, Horrible, No Good, Very Bad Day
    • Be Careful What You Wish For

    Tip: There are various online converters available.

  • An operation that opens a new popup or window should end with an ellipsis ("...").

  • Avoid redundancy. For example do not use Enable, Activate, Is, Use, or similar words for boolean properties (e.g. labels in checkboxes).

    Example

    Don't: Use Transparency
    Do: Transparency