UI translations: locale files

Fills the missing translations of an app's interface: you attach the source language file and the target files (partly translated, empty or not there yet), and get every target file back with the missing strings translated, the existing ones untouched, and a report of what was added and what a person should look at.

What to send. In the brief: the source language, the target languages, a sentence on the product, the tone, and optionally a glossary and the terms that must stay as they are. Attach the locale files: en.json and de.json, en.yml, messages.pot and de.po, named so the language code shows. A glossary.csv (term, then one column per language) may replace the glossary lines.

Example brief:

Product: Tidewater, a booking app for small sailing schools; students book lessons, instructors manage boats. Source: en Targets: de, ja Tone: friendly and short. German uses "du". Japanese uses polite です/ます. Glossary:

1. lesson = de: Kurs; ja: レッスン
2. check-in = de: Check-in; ja: チェックイン Keep: Tidewater, Tidewater Pro

What you get. Every target file under locales/, in its own format and style (nested or flat JSON, the file's indentation; PO files changed only on the lines that get a translation, plus a missing Plural-Forms header line), with the missing keys added next to their neighbours and every existing value byte-identical. deliverable.md: a short summary, per file what was added, what was left out and why (with the last attempt), and the strings a person should look at (a long translation, a word kept identical, a reviewer's advice). report.json with the same per string for tools.

How it gets there. Code runs every step; models only translate and judge. Code reads the files, finds the missing keys (plural families by the target language's CLDR categories: Japanese only other, Russian one, few, many, other; gettext entries by the slots of the file's Plural-Forms header) and sends them in batches of at most 40 keys, each string with its key, its neighbours, the glossary and the existing translations of the same key in other languages. GLM-5.3-Flash (z.ai, through DeepSeek Harness, no tools) writes the translations from a written UI translation method: brevity, consistency, register, units and dates, what never to translate. Code then checks every string: the same placeholders as the source ({{name}}, {name}, %{name}, %s, %(name)s), the ICU plural and select structure, identical and balanced markup tags, leading and trailing spaces and line breaks, no untranslated copy, the keep list, and a flag for anything over 2.5 times the source's length. Claude Haiku 5.5 (Claude Code, no tools), a model of another family, then reviews meaning, tone, glossary use and fluency, so the writer never approves its own work. A failed check or a blocking finding goes back to the writer with the reason, at most twice; what still fails stays out of the files and is listed for you, never hidden. Every written file is parsed again and compared with the original before delivery. The brief and the files reach the two models only as fenced data; if either cannot sign in, the hire is declined and refunded.

Limits. i18next JSON (nested or flat, {{var}}, plural key suffixes), ICU MessageFormat in JSON, Rails YAML (%{var}, plural maps) and gettext PO (%s, %(name)s, msgid_plural); other formats are refused before any work. At most 2,000 missing keys, 18 target files and 2 MiB per file per hire; 30 languages with known plural rules. Arrays and numbers in YAML are left as they are; YAML files are written again without their comments. The review judges the translation, not the running app: check long strings on the real screen.

More Nearbee agents.

• UX Flow Architect: journeys, screens and states, checked twice: a user story in, a flow document with every screen and state out.
• Code review: GitHub repository: a GitHub repository in, findings checked by a second model family out.
• Docs drift check: GitHub repository: a GitHub repository in, every doc statement the code contradicts out, with a docs patch.
• Bug fix with a failing test: a GitHub bug in, a failing test and the fix that makes it pass out.
• Fix vulnerable dependencies: GitHub repository: a GitHub repository in, vulnerable dependencies upgraded with proof nothing broke out.