Build a localization glossary

Without a glossary, each translator and each release picks its own word for the product's core concepts, so "Workspace" becomes three different words in German across one screen, and "Archive" and "Delete" blur together in a language where the first guess was a synonym. A good term base is short, covers the terms that carry product meaning or appear everywhere, defines each one so translators understand the concept rather than the English word, and settles brand names once.

Build a localization glossary from these strings:

[SOURCE_STRINGS]

Target locales: [LOCALES] Product context: [PRODUCT_CONTEXT]

1. Extract candidate terms:

• product objects and features ("Workspace", "Board", "Snapshot");
• recurring UI actions whose differences matter ("Archive" versus "Delete" versus "Remove", "Sign in" versus "Log in");
• domain terms that users must understand precisely;
• brand, product and plan names, and code-like tokens. Skip generic words that any translator handles consistently.

1. Check the source for its own inconsistencies first: the same concept named two ways, or one word used for two concepts. Report them, because they must be fixed in the source or the glossary will encode the confusion.
2. For each term, record its part of speech, a one-sentence definition of the concept in this product, a real usage example taken from the strings, and whether it is do-not-translate.
3. Propose a translation per locale:

• For standard concepts (Settings, Preferences, Sign in, Share), follow the target platform's published UI terminology; Microsoft and Apple both publish localized term lists. Note where the two differ.
• For inflected languages, give the grammatical gender and the plural form.
• Pick a translation that keeps distinct source terms distinct.
• Note forbidden alternatives where a common choice would be wrong ("Do not use 'Löschen' for Archive").
• Mark every proposal as "proposed" for a native-speaking reviewer to approve.

1. Keep the glossary focused: at most 40 terms, ordered by how often they appear and how much meaning they carry.
2. If the product context is missing and the strings do not make the concepts clear, ask up to 3 questions about the terms that matter most, and build the rest.

• Never present a proposed translation as approved or authoritative.
• Do-not-translate terms are only brand names, product names, trademarks, code identifiers and terms the context says to keep. Ordinary words are not do-not-translate just because they are capitalised.
• Separate what you verified from what you inferred. Mark inferences as such.
• When you do not know, say "I don't know" once and state what would settle it.

Source inconsistencies

| Concept | Variants found | Example keys | Recommended single term | "None" if there are none.

Glossary

| Term | Part of speech | Definition | Example from the strings | One column per locale: proposed translation (gender and plural where relevant) | Notes and forbidden alternatives |

Do not translate

One line each, with the reason.

Export

The glossary as CSV in a code block, with columns term,pos,definition,dnt,<locale>...,notes, ready to import into a translation management tool.