better-writinglisted

# Interface writing Clear and brief beats clever; consistent beats varied. The best error message is the interaction redesigned so the error cannot happen. How copy renders (capitalization via `text-transform`, truncation, smart punctuation) belongs to `better-typography`. Error markup and announcements (`aria-invalid`, live regions) belong to `better-accessibility`. Room for translated strings belongs to `better-layout`. ## Recon the existing voice Before writing or reviewing, read the copy nearby. Note the product's terminology, its localization conventions and any voice or content style guide. A deliberate brand voice is not a defect. Raise a departure from plain language only when it creates inconsistency, ambiguity, translation risk, or a tone the stakes don't support. ## One voice, flexible tone The product has one voice and its existing copy establishes it. A local edit does not get to invent a new one. Keep terms consistent: if it's "Archive" in the menu, it isn't "Move to storage" in the toast. Tone flexes with the stakes: | Context | Tone | | --- | --- | | Success, onboarding, empty states | Warm, can be light | | Routine actions, settings | Neutral, minimal | | Errors, destructive confirmations | Calm, plain, zero playfulness | | Data loss, security | Serious, explicit | ## Address the reader directly In instructional copy, write "you", not "the user". In errors, "we" invites ambiguity and reads as deflection, so prefer "Unable to load content" over "We'r