Generic MT translated our API parameter names and broke all the code examples.
Flixu's localization pipeline separates code from text before translation begins. JSON keys, HTML tags, Markdown syntax, variables, and code blocks are preserved exactly. Only the human-readable text is translated. Your build doesn't break. Your docs don't need manual syntax fixes.
Flixu connects to your repository through the GitHub App or the Developer API. When you push new strings, Flixu detects the changes, translates the translatable text with your Glossary and Brand Voice applied, and commits the translated files to a dedicated branch. Code structure is preserved exactly — keys, variables, tags, and code blocks are never translated. Your CI/CD pipeline picks up the localized files alongside the English ones.
Localization breaks your code and falls behind your releases.
The typical pattern: a developer builds a feature in English, extracts the new strings, uploads them to a translation tool, waits for translations to come back, merges the translated files, and discovers one of three things: the JSON keys got translated and the app crashes, the Markdown formatting is broken and needs manual fixing, or the translations arrived two days after the feature shipped and the German version is missing content.
These aren't edge cases. They're the structural outcome of using tools that weren't built for code files.
From the developer community:
"Generic MT translated our API parameter names and broke all the code examples."
"Markdown formatting gets destroyed when we run it through translation tools."
"We want docs-as-code for localization too, not a web uploader."
"Our Japanese docs are two versions behind because updating them manually is too slow."
The answer isn't more careful post-processing. It's a pipeline that understands the difference between code structure and translatable text before generating anything.
Code structure gets preserved — always.
When Flixu processes a file, the parser extracts only the translatable values. Keys, structural identifiers, variable names, HTML tags, Markdown syntax, and code blocks stay exactly as they are in the source. The model translates the human-readable text; it never receives the structural elements.
Source (English)
{
"checkout": {
"title": "Complete your purchase",
"discount_msg": "Save {{percent}}% with code <strong>WINTER</strong>"
}
}
Output (German)
{
"checkout": {
"title": "Kauf abschließen",
"discount_msg": "Sparen Sie {{percent}}% mit dem Code <strong>WINTER</strong>"
}
}
The variable {{percent}} is preserved. The HTML tag <strong> is preserved. The key discount_msg is preserved. The German text is built around those structural
elements — not inserted into them after the fact.
This applies to Markdown files too: heading syntax, link structures, code blocks, and inline code are all preserved in the output file. The exported file is syntactically valid Markdown — no manual syntax patching required.
→ File format support and parsing: Document Translation
Translations commit to your repository when you push English strings.
The Flixu GitHub App watches your monitored file paths. When a developer pushes changes to those files, the app detects the new or changed strings, runs the translation pipeline with your Glossary and Brand Voice applied, and commits the translated files to a dedicated localization branch — separate from your feature branches.
# Conceptual configuration — see documentation for exact syntax
source_language: en
target_languages: [de, fr, ja, es]
watch_paths:
- "src/locales/en/**"
- "docs/en/*.md"
translation_branch: "localization/automated"
The feature branch and the localization branch never touch the same files simultaneously. The merge conflicts that occur when a TMS bot and a developer both write to the same localization file — the ones that stop sprints — don't happen here.
For teams using docs-as-code workflows, documentation updates trigger the same pipeline. A new version of the API documentation committed to the repository generates translated versions automatically, without a manual upload step or a version delay.
→ GitHub App setup and configuration: GitHub Integration
API terminology stays consistent across languages and versions.
A glossary entry for "Authentication" specifies the approved German term "Authentifizierung" — not "Authentisierung" or any other variant. Every translation request that touches the word "Authentication" in a German context applies the approved term, regardless of which file it appears in or when it was translated.
For API documentation teams, this matters across versions. If Version 2.0 of your documentation uses the same glossary as Version 1.0, the term appears identically in both — your developers reading the German docs across versions encounter consistent terminology.
The glossary constraint is applied before translation begins. The model doesn't receive a suggestion to use the approved term; it receives the term as a specified constraint in the payload. In inflected languages like German or Japanese, the surrounding grammar is built around the fixed term from the start.
→ Glossary enforcement: Glossary Enforcement
How the developer workflow works.
Option 1 — GitHub App recommended for CI/CD pipelines
Install the GitHub App, configure the file paths you want to monitor, and link the repository to a Flixu workspace project. From that point, every push that touches monitored files triggers the translation pipeline automatically. Translations commit to the dedicated localization branch. The setup takes under 15 minutes.
→ Full setup guide: GitHub Integration
Option 2 — Developer API for custom integrations
The Developer API provides programmatic access to the full translation pipeline. Pass source text and receive translated output in the same call, or use webhooks for asynchronous processing of larger batches. All API calls run with your workspace context — Glossary, Brand Voice, and Translation Memory are loaded based on the authenticated workspace, not passed per-request.
→ API reference and authentication: Developer API
Option 3 — AI Agents for in-context tasks
Flixu's MCP integration lets you invoke translation directly from Claude Code, Cursor, or any MCP-compatible AI assistant. Translate specific strings, test glossary configurations, or run quick localization checks without leaving your coding environment.
→ AI Agent integration: AI Agents
What's different about how Flixu handles developer files.
Most translation tools with developer integrations work by syncing files and providing MT output. The structural preservation and the branch model are where the behavior differs:
Structure preservation
Flixu's parser extracts translatable values, translates them, and reconstructs the original file structure — keys, variables, nesting, and formatting intact. Files that pass through Flixu don't need structural repair.
Branch isolation
The localization branch is separate from feature branches. The TMS bot and the development workflow never write to the same files simultaneously. No three-way merge conflicts.
Deterministic output
The models Flixu uses for translation — Qwen and DeepInfra routing configured for translation tasks — don't add commentary, don't rephrase structural elements, don't alter variables. The output is constrained to the translation task. For CI/CD pipelines that run automatically, that predictability is what makes auto-approval safe.
Frequently Asked Questions
Which file formats does the API support?
+
JSON, YAML, XLIFF, iOS .strings, .po / POT, Markdown, and subtitle files. For each format, the parser preserves the structural elements — keys, tags, variables, code blocks, Markdown syntax — and extracts only the translatable text. Android XML is not currently supported; check the documentation for the current format list before integrating for Android projects.
How does Flixu protect code blocks and variables from being translated?
+
The parser identifies structural elements — JSON keys, HTML tags, Markdown code fences, interpolation variables like {{variable}} or {name} — and excludes them from the text that's sent to the language model. The model only receives the human-readable text. The structural elements are re-injected into the output file from the preserved source structure.
How do I authenticate API requests?
+
All API requests authenticate using Bearer tokens generated from your Flixu workspace. The token is scoped to your workspace — Glossary, Brand Voice, and Translation Memory configurations associated with that workspace are applied automatically to all requests made with that token.
Does Flixu support webhooks for async translation?
+
Yes. For larger batches or when integrating into pipelines where synchronous responses are impractical, webhooks deliver the translated payload when processing is complete. The Developer API documentation covers webhook configuration and payload format.
Can I test the integration before committing to a paid plan?
+
Yes. The free tier includes API access and translation credits — enough to integrate the GitHub App or Developer API and validate structural parsing against your actual codebase before scaling. The free tier applies the same Glossary and Brand Voice configuration as paid plans.
How does Flixu handle missing translations for a locale that hasn't been configured?
+
The API supports configurable fallback behavior for missing translations or unconfigured locales: fall back to the source language string, return an empty string, or return a specified fallback value. This prevents frontend UI failures when a locale isn't fully translated yet.
Connect your repository and ship localized features on the same timeline as English.
Install the GitHub App, configure your file paths, and push a commit. The first translation runs automatically — no dashboard step, no manual file management.
Related Features
- GitHub Integration — Git-native localization with dedicated branch model
- Developer API — Programmatic access for custom CI/CD integrations
- AI Agents — Trigger translations from inside your AI coding assistant
- Glossary Enforcement — API terminology consistency across versions
- Auto-Approval Workflows — LQA-based zero-touch deployment for CI/CD
- Document Translation — File format support and structural parsing