Translation key
The stable ID like 'checkout.button.pay' that the code asks for, so every locale can answer with its own wording.
See it
What it is
A translation key is the stable name your code asks for instead of the sentence itself. The component says t('checkout.button.pay') and the active locale's catalog answers with 'Pay now', 'Jetzt bezahlen', or 'Pagar ahora'. The key never changes when the copy does, which is the whole point.
Two schools. Semantic keys ('cart.empty.title') are namespaced by feature, survive copy edits untouched, and force you to open the catalog to see what a screen says. Source-text keys (the English string is the key) keep the code readable, but fixing one typo in the source orphans every translation of that string. That style is one convention among several, not a shared default: Lingui supports natural-language IDs, while FormatJS uses message IDs that you either write explicitly or generate from the message and its metadata. Pick one convention and enforce it, because half a codebase in each is the worst outcome.
Gotcha: do not reuse one key just because two places show the same English word. 'Open' as a button verb and 'Open' as a ticket status are different words in most languages, and a shared key makes one of them wrong forever. Same trap in reverse: keys named for their appearance ('blue_button_2') tell translators nothing, so name them for meaning and attach context notes.
Ask AI for it
Define a translation key convention for this project and apply it. Use lowercase dot-notation keys namespaced feature.component.element (for example 'settings.billing.cancelButton'), named for meaning rather than appearance or current wording. Give every distinct usage its own key even when the English text is identical, so words like 'Open' can diverge per language. Attach a context comment to each key stating where it renders and what any placeholder contains. Add a type-safe t() wrapper that autocompletes valid keys and fails the build on a key missing from the source catalog.