Glossary generation

Translators meet a product's vocabulary one string at a time, with no way to tell which words are the product's own. A glossary is where a term gets decided once — translated one way everywhere, or not translated at all — and it is worth most before the first translation is made rather than after fifty of them disagree.

The glossary this skill produces is a starting point, not a finished asset. Ten to thirty terms a localization manager can accept, edit, or delete beats two hundred that read as noise; the second kind gets deleted wholesale, which also throws away the few good entries in it. Treat forty terms as a hard ceiling, and prefer leaving a doubtful term out — a missing entry costs one inconsistent translation, a wrong one teaches every translator the wrong answer.

For the glossary command's full flag set, read the crowdin-cli skill's commands reference; below are only the flags this skill passes.

Inputs

Three things, resolved before any term is picked:

• The source strings. Read the source catalog — the file crowdin.yml uploads, at its resolved source pattern — not the source tree. Those are exactly the strings translators will see, already stripped of code. When there is no crowdin.yml, ask the user where the source-language strings live rather than scanning code for them.
• A one-line product description. This is what makes "brew" a domain term in a coffee-logging app and an ordinary verb anywhere else; without it, term selection degenerates into picking capitalized words. Ask for it if nothing in the conversation or repository supplies one.
• A draft location outside version control — a scratch directory, or a gitignored path the caller names — so a rejected draft never lands in the repository.

What earns an entry

A term qualifies when a translator, seeing it in one string with no other context, could reasonably get it wrong. In practice that is four kinds: