focusreactive / focusreactive/payload-plugins

[translator] Epic: translation style controls — glossary, tone & brand voice

Open
#142 0 comments 0 reactions 0 assignees View on GitHub
enhancement epic high priority translator
Dominant language
TypeScript
Stars
19
Forks
0
Avg merge
16h 54m
Merged PRs (30d)
19

Description

## Summary

Add first-class, structured control over **how** content is translated — a glossary, tone/voice, and protected (do-not-translate) terms — instead of relying only on a free-form system prompt.

## Motivation

Comparable tools (e.g. Sanity AI Translations) expose brand-voice controls as structured, maintainable settings rather than prompt text:

- a **glossary** of preferred/forbidden term translations per locale, with a do-not-translate flag;
- a **style guide** for formality and tone/voice;
- **protected phrases** the model must never translate (brand names, product names, set terms).

Today our plugin can only influence this through the system prompt, which is hard to maintain, not per-term, and not enforceable. This epic closes the most significant capability gap versus Sanity.

## Scope (high-level — to be refined)

- **Glossary**: preferred and forbidden translations per term, per target locale; a do-not-translate flag.
- **Tone / style**: formality and voice guidance applied consistently to translation requests.
- **Protected terms/phrases**: a hard constraint so listed terms are passed through untranslated.
- Make these **editable and maintainable** (config and/or editor-facing) and feed them into the translation prompt automatically.
- Consider hard (rule-based) vs soft (prompt-level) enforcement, and how quality is validated.

## Notes

- Data model, enforcement strategy and UX to be defined in follow-up sub-issues.
- Relates to the async system-prompt builder (#109) and the provider abstraction.

Priority: **High**. Details are intentionally high-level for now; sub-issues will follow.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by reading the async system-prompt builder in #109 and the provider abstraction referenced in the issue. The scope is intentionally high-level, so this epic should first be refined into sub-issues that define the data model, enforcement strategy, editor or configuration surface, and validation criteria before implementation begins.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
localization
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.