Mag-skip sa main content

Architecture

Ang Rosetta translation ecosystem ay binubuo ng tatlong independent tools na nagtutulungan through well-defined contracts. Wala sa kanila ang naka-depend sa isa't isa at build time. Nag-co-communicate sila through a shared method plugin format at isang REST API contract.

Ang Tatlong Components​

i18n-rosetta (ang project na ito)​

Ang open-source developer tool. Nagta-translate ito ng locale files gamit ang pluggable methods. Zero dependencies, config-optional, at works out of the box.

Built-in methods:

  • llm → OpenRouter / any LLM (200+ models)
  • llm-coached → LLM + grammar/dictionary coaching
  • openai → Direct OpenAI API (GPT-4o, GPT-4o-mini)
  • anthropic → Direct Anthropic API (Claude Sonnet, Haiku, Opus)
  • gemini → Direct Google Gemini API (Flash, Pro — may free tier)
  • google-translate → Google Cloud Translation API v2
  • deepl → DeepL API na may glossary support
  • microsoft-translator → Azure Cognitive Services Translator
  • libretranslate → Self-hosted LibreTranslate (AGPL, libre)
  • api → Thin pipe papunta sa kahit anong remote REST endpoint

Eval Harness (companion project)​

Isang research tool para sa pag-develop, pag-test, at pag-benchmark ng translation methods. Kapag umabot na sa acceptable quality ang isang method, mag-e-export ang harness ng isang method plugin — isang method.json manifest at optional na coaching data files.

Hindi kailanman nagra-run ang harness sa loob ng rosetta. Isa itong separate tool na nagpo-produce ng static output (JSON files). Binabasa lang ng Rosetta ang mga files na ito.

→ Eval Harness sa GitHub

Rosetta Translate (planned)​

Isang metered API service na nagho-host ng proprietary translation methods sa server-side — ang mga prompts, coaching data, at linguistic pipelines ay hindi kailanman lumalabas ng server.

Paano Sila Naka-connect​

Eval Harness → i18n-rosetta (one-way export)​

Contract: Plugin Specification

Rosetta Translate → i18n-rosetta (API at runtime)​

Ang APIMethod ng Rosetta ay isang dumb pipe. Nagse-send ito ng keys palabas at tumatanggap ng translations pabalik. Wala itong kahit anong translation logic at zero proprietary content.

Ano Ang Alam Ng Bawat Component Sa Isa't Isa​

ToolAlam ang rosetta?Alam ang Rosetta Translate?Alam ang harness?
i18n-rosetta(ito ang rosetta)Oo — tinatawag ito ng api methodHindi — nagbabasa lang ng plugin exports
Rosetta TranslateOo — nagse-serve ng requests nito(ito ang Rosetta Translate)Hindi — tumatanggap ng deployed methods
Eval HarnessOo — nag-e-export ng plugin formatHindi — hiwalay na naka-deploy ang methods(ito ang harness)

User Scenarios​

Scenario 1: Libre, zero-config (karamihan ng users)​

export OPENROUTER_API_KEY=sk-...
npx i18n-rosetta sync

Gumagamit ng built-in na llm method. Walang plugins, walang Rosetta Translate, walang harness.

Scenario 2: Google Translate baseline​

export GOOGLE_TRANSLATE_API_KEY=AIza...
npx i18n-rosetta sync

Gumagamit ng built-in na google-translate method. Hindi kailangan ng plugins.

Scenario 3: Open plugin na may bundled coaching​

rosetta plugin install ./french-formal-v1/
rosetta sync

May type: "llm-coached" ang plugin → ginagamit ng rosetta ang sariling OpenRouter key ng user. Local ang coaching data (walang server call).

Scenario 4: DIY coaching (walang plugin, walang harness)​

i18n-rosetta.config.json
{
  "pairs": {
    "en:fr": { "method": "llm-coached" }
  }
}

Mina-maintain ng user ang sarili nilang grammar rules at dictionary sa .rosetta/coaching/fr.json.

Design Principles​

  1. Walang circular dependencies. One-way lang ang mga bridges.
  2. Ang Rosetta ang lightweight core. Zero dependencies, config-optional. Additive ang mga plugins at API.
  3. Architectural ang IP protection. Nananatili sa server-side ang proprietary techniques. Walang shini-ship na proprietary ang npm package.
  4. Ang plugin format ang contract. Dumadaan ang lahat sa method.json.
  5. May iisang trabaho ang bawat tool. Harness → mag-develop ng methods. Rosetta Translate → mag-host ng methods. Rosetta → mag-translate ng files.

See Also​