Most translation tools process your strings. Flixu reads your document first.
Before a single word is translated, Flixu runs a five-dimension analysis — detecting your domain, formality register, target audience, brand voice rules, and cultural context. That analysis changes everything that follows.
Generic machine translation processes text sentence by sentence, without knowledge of what came before or what the overall document means. Flixu's approach is different: it reads the whole document first, assembles your glossary rules and brand voice configuration, and only then begins translating — producing output that is consistent across the entire document, not just each isolated string.
Why sentence-by-sentence translation breaks at scale.
When a generic API processes your product interface string by string, it has no memory of what it translated ten segments ago. "Dashboard" in your navigation header becomes "Tableau de bord." The same term in your settings panel becomes "Panneau de contrôle." Both are technically correct French words. Neither is what your team approved. By the time the inconsistency surfaces — usually when a customer notices it, or when a developer merges a broken JSON file — the release is already delayed.
This is the core problem the Flixu Method addresses. It isn't about using a different AI model. It's about changing the order of operations: analysis first, translation second. According to CSA Research, 76% of software buyers prefer to use products in their native language — but preference turns to frustration when the translation is inconsistent. The quality gap between "technically translated" and "actually correct for this product" is where most localization pipelines fail.
→ See the technical comparison: Context-Aware vs. Traditional Machine TranslationHow the analysis-first pipeline works.
Step by StepEvery translation request in Flixu passes through the same sequence before the language model generates a single word. The steps below are not optional layers — they run on every request, in order, for every language pair.
Document Ingestion & Format Parsing
Flixu accepts your file as-is: .docx, XLIFF, .po, .yaml, .strings, Markdown, or subtitle files. The parser extracts only the translatable text, preserving all structural elements — tags, placeholders, code keys, formatting anchors — exactly as they appear in the source. The file that comes back out is structurally identical to the file that went in. Your developers don't fix broken tags. Your layout doesn't shift.
→ How format preservation works in practice: Document TranslationWhole-Document Context Scan
Rather than queuing individual strings for translation, Flixu reads the entire document before processing any of it. This matters because meaning is distributed: a term introduced in paragraph one has consequences for paragraph twelve. A subject established in your app's onboarding flow affects how a support article should be phrased. Whole-document reading gives the model the structural narrative it needs before individual strings are touched.
Pre-Translation Analysis (The 5 Dimensions)
This is the analytical core of the Flixu Method. Before translation begins, the engine runs a five-dimension classification across your document. The output of this step is a structured analysis profile that governs every subsequent decision in the pipeline.
→ Deep dive into the five dimensions: The Context EngineTranslation Memory Retrieval & Glossary Injection
Before the language model receives the text, two things are assembled and loaded. First, the Translation Memory — a Semantic Reranker identifies past translations that are structurally and conceptually similar to the current string, even when the exact words differ. These matches are used as style references, not as blind substitutions. Second, the glossary — every corporate term you've defined is injected as a hard constraint before the model begins. Teams using enforced glossary workflows typically see terminology inconsistency drop from 15–25% of reviewed strings to under 2%.
→ Glossary enforcement in detail: Glossary Enforcement → How Translation Memory works: Translation MemoryDeterministic Translation
The assembled payload — document context, analysis profile, TM references, glossary constraints, brand voice rules — is routed to the language model. Flixu uses Qwen and DeepInfra model routing, optimized for translation-specific tasks rather than general generation. The model operates within the constraints assembled in the previous steps. It cannot produce a synonym for a term that your glossary has explicitly defined. It cannot adopt a tone that contradicts your brand voice configuration.
→ How brand voice configuration works: Brand Voice ManagerAutomated Quality Scoring (LQA)
Every translated segment receives an automated Linguistic Quality Assurance score across five dimensions: grammar, accuracy, terminology consistency, formatting, and fluency. Segments that score above the threshold, or that match your Translation Memory at 99% or higher, are automatically approved and deployed without requiring human review. Segments that fall below are routed to a human reviewer with the specific dimension flagged.
→ Full LQA workflow: LQA & Quality Assurance → How auto-approval works: Auto-Approval Workflows| Dimension | What it detects | Why it matters |
|---|---|---|
| Domain | Legal, SaaS UI, medical, marketing, technical | Vocabulary register changes entirely by domain |
| Formality | Formal (Sie) vs. casual (du); register calibration | Wrong formality alienates users in DACH, Japan, Brazil |
| Cultural Context | Date formats, currency, measurements, regional idioms | "Baseball analogy" in a DACH campaign lands as foreign content |
| Brand Voice | Tone definition, phrasing constraints, stylistic preferences | Prevents the "corporate brochure" problem |
| Situational Context | UI string vs. long-form copy vs. legal clause vs. ad headline | Each context type requires different translation behavior |
What happens after a human reviewer makes a correction?
Every edit a reviewer makes in the Flixu workspace feeds back into the Translation Memory and the Post-Edit Learning Loop. The system registers the correction, updates the style reference, and adjusts future behavior — so the same pattern is handled correctly the next time it appears, across all language pairs. Teams that start with a limited Translation Memory accumulate stylistic precision over time rather than repeating the same review cycles indefinitely.
This is the compounding return of a context-first approach: each approved correction makes subsequent translations more accurate, not just within the current project but across every future one that shares the same workspace.
How this compares to the alternatives.
| Raw MT (e.g. DeepL API) | Legacy TMS (e.g. Phrase) | Flixu Method | |
|---|---|---|---|
| Translation unit | Sentence by sentence | String by string | Whole document first |
| Brand voice | Not configurable | Manual prompting, agent-dependent | Programmatic, injected per request |
| Glossary enforcement | None | Optional, post-hoc QA | Mandatory, pre-translation constraint |
| Translation Memory | None | Fuzzy-match substitution | Semantic reranking as style reference |
| Quality scoring | None | Manual or third-party | Automated LQA on every segment |
| Developer workflow | API call, no TM | File upload + manual merge | Git-native, branch-safe |
| Learning loop | None | Manual TM updates | Automatic post-edit feedback |
| Setup time | Minutes | 6–9 months | Days |
Raw MT is appropriate for informal, high-volume, low-stakes content where consistency isn't a requirement. A legacy TMS is appropriate for large enterprise workflows with dedicated localization teams and established agency relationships. Flixu is built for the gap between those two: teams that need consistency and control, without the infrastructure weight.
→ See specific comparison: Flixu vs. DeepLFrequently Asked Questions
Does the five-dimension analysis run on every translation, or only the first time?
+
It runs on every request. The analysis isn't a one-time profile that gets cached — it responds to the specific document each time. A marketing email and a technical changelog from the same client will receive different analysis profiles, and therefore different translation behavior, because they are genuinely different content types.
What happens if my Translation Memory is empty or very small?
+
Flixu works without an established TM — the Semantic Reranker identifies structurally similar past translations even from limited history. For brand-new workspaces, the brand voice configuration and glossary carry more of the consistency load. Quality improves as the TM grows, but the pipeline is functional from day one. Teams typically see the biggest improvement jump after 50–100 approved segments.
Does this work inside a CI/CD pipeline without a human triggering each translation?
+
Yes. The GitHub App detects new or changed strings when a developer pushes to the repository, runs the full analysis-and-translation pipeline automatically, and commits the translated files back into a separate branch. A developer can go from English commit to translated output across 22+ languages without touching the localization workflow manually. Teams that move from manual file uploads to Git-native workflows typically reduce localization coordination time from several hours per sprint to under 30 minutes.
How does Flixu handle languages with complex formality rules — like German Sie/du or Japanese keigo?
+
Formality calibration is handled by the Pre-Translation Analysis layer as one of the five dimensions. You define the target formality level once in your brand voice configuration (or the engine infers it from document context). That setting is injected as a constraint before translation begins — the model cannot produce mixed formality output because the instruction is part of the payload, not a post-hoc check.
What about data privacy? Are my documents used to train shared models?
+
No. Your documents, strings, and Translation Memory data are processed within your workspace and are not used to train public or shared AI models. Input data is processed ephemerally and not retained beyond the active session.
Is Flixu appropriate for regulated industries like legal or healthcare?
+
The core features — enforced glossary, terminology consistency, LQA scoring, deterministic output — are directly relevant for regulated content where specific terminology cannot drift. Teams working with compliance documents, contracts, or medical content should also review the LQA documentation and Legal industry page for specifics.
How does the learning loop affect existing Translation Memory entries?
+
Post-edit corrections update the TM going forward — they don't overwrite historical approved segments. The system treats each correction as a new signal about your stylistic preferences, not as a retroactive correction of past work. If a correction produces an apparent conflict with an existing TM entry, the entry is flagged for human review rather than automatically updated.
See what the pipeline produces with your own files.
Deniz built Flixu after a decade in B2B SaaS localization workflows. He writes about the technical decisions behind the platform at Flixu Notes.