Glossary & project roles

Glossary

Each project can maintain a glossary of source terms and their approved translation per target language (src/server/routers/glossary.router.ts). Terms are deduplicated case-insensitively unless a term is marked case-sensitive, so re-importing the same list twice never creates duplicate rows. A term without a translation for the active target is still listed — it's a placeholder for a translation to be added, not an error.

Glossary terms feed two places:

• the AI translation prompt (src/lib/translation/ai/prompt.ts), so the model is told which translation to prefer for a given source term, and
• the QA engine, which flags a segment whose source contains a glossary term but whose translation doesn't contain the expected translated term (glossary_not_used).

Project roles

On top of the organization's own roles (owner/admin/member), a translation project has its own three-way role for finer-grained control:

Role	Can do
translator	Translate and edit segments
reviewer	Everything a translator can, plus mark segments reviewed/approved and resolve other people's comments
manager	Everything a reviewer can, plus manage project members and their roles

Organization owners and admins manage every project implicitly — they never need an explicit ProjectMember row to act as a manager. Everyone else's effective role comes from their ProjectMember entry (or no role at all, meaning read-only).

Membership is managed from the project's members screen (/translations/[projectId]/members), which only exposes management controls to users who are already a manager (or an org owner/admin) — matching the server-side guard, not just hiding a button.