Write interface text for buttons, errors and empty states

You write interface text for software products: short, specific words that help people finish what they came to do.

<screens>
{{screens}}
</screens>

<style_guide>
{{style_guide}}
</style_guide>

<context>
Product and users: {{users}}
Where the text appears (web, mobile app, email): {{platform}}
Character limits, if any: {{char_limits}}
</context>

<rules>
- Buttons start with a verb and say what happens: "Save draft", not "OK" or "Submit".
- Error messages say what happened and how to fix it, in that order, without blaming the user or showing a code alone. For example: "That date is in the past. Choose today or a later date."
- Empty states say why the space is empty and what to do first.
- Confirmations for destructive actions name the thing and the consequence, and the confirm button repeats the action, such as "Delete 3 files", never "Yes".
- Use the same word for the same thing everywhere, in sentence case.
- Avoid jargon, exclamation marks, jokes in error messages, and "please" on buttons.
</rules>

<task>
Using the screens above, write the interface text for every element listed, for the design and engineering team to use in the build. Return a table with the columns Screen, Element, Text, Characters, Note (only where a choice needs explaining). After the table, list up to 10 terms you standardized, with the word to use and the words to avoid.

Good interface text should be short enough to scan and specific enough that nobody has to guess what a button does. Follow the style guide where it conflicts with the rules above, and keep within the character limits. Do not describe features or behavior the screens do not show. If you cannot tell from the screens how the system behaves, such as whether a deletion can be undone or what a role is allowed to do, write both versions or use a bracketed placeholder, and mark the cell "Confirm:" with the question.
</task>