Localization at the speed of the sprint.
Your L10N files are already in the repo. Black Ice extracts new strings each sprint, governs them against your ontology and Market Definitions, and produces translated target files at a quality that goes straight to visual QA — no repair pass needed.
The repo ships every sprint. Localization doesn’t.
Strings are extracted, exported, translated in a separate tool, re-imported, broken, repaired, and re-reviewed. The pipeline lives outside the sprint. Black Ice puts it back in.
- L10N happens after the sprint, in a separate tool
- Strings exported to spreadsheets, re-imported broken
- Reviewers re-translate because the AI hallucinated terms
- Features for unavailable markets get translated anyway
- Terminology drifts release over release with no anchor
- L10N runs inside the sprint, against the repo
- Repo files are the TM — no export/import cycle
- Approved terminology injected as hard constraints
- LOCKED concepts halt translation before any cost
- Stable strings locked — drift is structurally prevented
Five stages. One sprint cycle.
From repo commit to approved translations in the locale files — without leaving the development workflow.
- 01git diff · sprint tag
Delta extraction
At sprint close, Black Ice diffs the source locale file against the last run tag. Only new and modified strings enter the pipeline. Stable strings are locked — the AI never re-touches them, so terminology drift can’t accumulate sprint over sprint.
- 02ontology governance
Concept check before translation cost
Every incoming string is checked against the live ontology. If the concept it references is LOCKED for the target market — a feature not yet available there — or on HOLD pending terminology review, the string is flagged and held. No translation cost for strings that can’t ship.
- 03AI translation
Consistent with what’s already in the repo
The translation agent loads approved terminology from the ontology and reads the existing target locale files as translation memory. New strings match what’s already shipped — same register, same term choices, same phrasing. No separate TM required.
- 04QA confirmation
Reviewer confirms, not re-translates
By the time a string reaches a reviewer, it has been governed by the ontology, shaped by the market definition, and made consistent with the existing repo. QA is a confirmation pass against visual context — not a translation exercise.
- 05PR · run tag
Commit to target files, tag the run
Approved translations are committed back to the target locale files via PR. The run is tagged on the source repo — the next sprint’s delta extraction starts from that tag. Clean, auditable, repeatable.
Strings that arrive at QA ready to confirm, not to fix.
The pipeline produces translated target locale files governed by three layers simultaneously: approved terminology from the ontology, Market Definitions, and consistency with what’s already in the repo.
Reviewer confirms or flags. Strings that pass ship to the target locale file in the next PR.
The agent adapts to your format. Not the other way.
You don’t reconfigure your repo for Black Ice. The agent reads your existing string files, learns their structure, and writes output back in exactly the same format. No conversion, no adapter layer, no broken diffs.
Nested key paths, ICU plural syntax, interpolation variables. Nesting depth and key casing — camelCase, snake_case, dot-separated — preserved exactly as found.
Indentation, anchor references, block scalars. Output is written back with the same whitespace conventions — no format drift that breaks your linter or your diff.
Platform-specific formats for Flutter, GNU gettext, iOS/macOS, and XLIFF-based tools. Metadata conventions — descriptions, developer comments, plural forms — preserved in the output.
Using a custom format? The agent can be trained on your structure. Bring your schema — it adapts.
Four signals this pipeline is yours.
- You localize JSON, YAML, ARB, or .po files and L10N is a post-sprint handoff
- Placeholders, length constraints, and format fidelity break because reviewers can’t see UI context
- You ship to markets with different feature availability and need unavailable strings blocked
- Terminology consistency breaks across releases without a shared concept layer
Repo-native pipeline
Reads your locale files, writes them back via PR. The repo is the TM. No separate translation tool to maintain.
Governance before cost
LOCKED and HOLD concepts halt strings before they translate. You never pay to translate copy you can’t ship.
Format-faithful output
Placeholders, plural syntax, key casing, and metadata preserved exactly. Output diffs cleanly against the source.
Common questions about product-string localization.
Make localization part of the sprint.
Connect the repo. Govern the ontology. Ship translated strings every sprint with QA that confirms instead of repairs.