Push English. Get translations back. No manual step in between.
The Flixu GitHub App watches your repository. When a developer pushes new or changed strings, it detects them, runs the translation pipeline with your Glossary and Brand Voice applied, and commits the translated files to a dedicated branch — without touching your feature branches, without a manual export, and without waiting for a project manager to start the process.
The Flixu GitHub App is a Git-native localization pipeline. When developers push new strings to a connected repository, the app automatically detects the changes, translates them using your configured Translation Memory, Glossary, and Brand Voice, and commits the translated files to a dedicated localization branch. High-confidence translations auto-approve; only flagged segments appear in the review queue. The English commit and the localized commits ship on the same timeline.
How the GitHub App works.
The structural difference from other GitHub integrations
Most localization tools with GitHub integrations work by syncing files — they detect changes, create PRs for translated content, and let you merge. The problem is that the PR model creates merge conflicts when the translation bot and the developer team both write to the same localization files. Crowdin's bot PR and your feature PR target the same file: the result is a three-way merge conflict that stops the sprint.
The Flixu GitHub App commits to a dedicated localization branch that's separate from your feature branches. The translation pipeline never touches your feature files, and your feature PRs never touch the localization files. The conflict doesn't happen.
Install the GitHub App
Install the Flixu GitHub App from the GitHub marketplace and connect it to your repository. You'll authorize access to the specific repositories you want to enable — nothing broader than what you authorize.
Configure file detection rules
Specify which files the app should monitor: file paths, file extensions, branch rules. Common configuration:
# Example Flixu GitHub App configuration
source_language: en
target_languages:
- de
- fr
- ja
- es
watch_paths:
- "src/locales/en/**"
- "public/i18n/*.json"
excluded_paths:
- "**/*.test.js"
translation_branch: "localization/automated"
The app monitors the paths you specify. Changes outside those paths don't trigger the pipeline.
Connect your workspace context
In the Flixu workspace, link the repository to a client profile or project. This loads the Glossary, Brand Voice, and Translation Memory that will apply to translations triggered by that repository. The context is set once at the repository level — every push after that applies the same configuration.
Developer pushes English strings
When a developer commits changes to monitored files and pushes to the configured branch, the Flixu GitHub App detects the new or changed strings, extracts the translatable text (preserving all structural elements — keys, variables, tags), and queues the translation pipeline.
Translation pipeline runs with context applied
The Pre-Translation Analysis runs: domain detection, formality calibration, Brand Voice injection, Glossary loading. The language model generates translations with all constraints active. LQA scores every segment.
Translated files committed to the localization branch
Translations that score above the LQA threshold (≥ 90/100) or match Translation Memory at ≥ 99% are auto-approved. The translated files — in the original format, with all keys, variables, and structure intact — are committed to the dedicated localization branch. Segments that fall below the threshold appear in the Flixu review queue with the failing dimension flagged. The commit waits for those segments to be reviewed and approved before including them.
Merge localization branch into main
When translations are ready, merge the localization branch. Your CI/CD pipeline picks up both the English changes and the localized versions — they're already committed and ready.
What the parser preserves.
The translation pipeline extracts only the translatable text. Everything structural — keys, variable names, HTML tags, placeholders, JSON nesting, YAML indentation — is preserved exactly in the output file.
Source (English)
{
"checkout": {
"title": "Complete your purchase",
"cta": "Pay {{amount}} now",
"error": "Payment failed. Try again."
}
}
Output (German)
{
"checkout": {
"title": "Kauf abschließen",
"cta": "{{amount}} jetzt bezahlen",
"error": "Zahlung fehlgeschlagen. Erneut versuchen."
}
}
Your application code doesn't need to change. The developer doesn't fix broken keys. The CI/CD pipeline picks up a valid, deployable file.
Supported file formats: JSON, YAML, .po / POT, iOS .strings, XLIFF, Markdown, subtitle files. Android XML is not currently supported — check the developer API documentation for the current format list before configuring for Android projects.
Why the branch model matters.
Teams that have used Crowdin, Lokalise, or Transifex's GitHub integration often run into the same structural problem: the TMS bot creates PRs for translated strings, and those PRs target the same localization files that feature branches are also modifying. When both PRs are open at the same time — which in a high-velocity team is almost always — the merge creates a three-way conflict.
Developer stops. Git history gets tangled. Someone spends 20 minutes resolving a conflict that has nothing to do with the feature they were building.
The Flixu app uses a dedicated localization branch. The feature branches and the localization branch never write to the same files simultaneously. The conflict can't happen because the files are separated at the branch level.
For teams that ship weekly or more frequently, eliminating that conflict source typically reduces localization-related sprint overhead from several hours to under 30 minutes.
→ B2B SaaS ICP workflows: Flixu for SaaS Teams
When Git-native localization changes the release economics.
SaaS teams with weekly releases
A weekly release cycle leaves no room for a separate localization cycle. The team that delays international releases by one sprint while translations are prepared is effectively shipping a two-class product: the English version and the international version, permanently offset. Git-native localization makes localization part of the same cycle — translations are committed when the English strings are committed, and the international release ships with the English release.
According to CSA Research, 76% of software buyers prefer products in their native language. For a product shipping weekly, that preference is only an asset if the localized version ships on the same timeline.
→ SaaS localization workflow: Flixu for SaaS Teams
Mobile app teams with CI/CD pipelines
Mobile apps with continuous delivery pipelines — new builds triggered by commits, strings bundled at build time — require localization to be ready before the build runs, not after. A Git-native integration commits translated strings to the localization branch before the build picks them up. The translated strings are in the build; no post-build localization patch is required.
→ Mobile app localization: Flixu for Mobile Apps
Documentation teams using docs-as-code workflows
Technical documentation managed in a repository alongside code — Markdown files, MDX, or structured content formats — benefits from the same Git-native approach. When documentation is updated, the translation pipeline runs automatically on the monitored paths. The translated documentation is committed to the localization branch and ready for deployment on the same schedule as the English documentation.
→ Software string translation: Software String Translation
Frequently Asked Questions
How does Flixu's GitHub integration prevent merge conflicts?
+
The Flixu GitHub App commits translated files to a dedicated localization branch that's separate from your feature development branches. Your feature PRs and the localization commits never target the same files simultaneously. The three-way merge conflicts that occur when a TMS bot and a feature branch both write to the same localization files — a common problem with Crowdin, Lokalise, and similar tools — don't happen because the files are structurally separated at the branch level.
Does the GitHub App require access to my entire repository?
+
No. When you authorize the GitHub App, you specify which repositories it can access. Within each repository, the configuration file specifies which file paths it monitors — you can scope it to your localization directories only. The app doesn't read or write to files outside the paths you configure.
What happens when a translation doesn't auto-approve?
+
Segments that score below the LQA threshold appear in the Flixu review queue with the specific failing dimension marked. The commit to the localization branch waits for those segments to be reviewed and approved. High-confidence segments that have already auto-approved are committed immediately; the flagged segments are held until a reviewer addresses them.
What file formats does the GitHub integration support?
+
JSON, YAML, .po / POT, iOS .strings, XLIFF, Markdown, and subtitle files. Android XML is not currently supported — if your project uses Android XML, check the developer API documentation for the current support status before configuring. For formats not in the list, the Developer API provides programmatic access to the translation pipeline that you can integrate into your own automation.
How long does the GitHub integration take to set up?
+
Under 15 minutes for a standard configuration: install the GitHub App, authorize repository access, create the configuration file specifying monitored paths and target languages, link the repository to a Flixu workspace project. The first translation run happens automatically on the next commit that touches the monitored paths.
Does the integration work with GitHub Actions?
+
The GitHub App runs independently of GitHub Actions — it responds to push events directly without requiring an Actions workflow. If you want to integrate Flixu into an existing GitHub Actions workflow instead of using the App, the Developer API supports that path with webhook-based triggering.
Can the GitHub App handle repositories with multiple applications or teams?
+
Yes. Configuration files can specify different monitored paths, target languages, and Flixu workspace contexts within the same repository — for monorepos where multiple applications share a repository. Each path configuration maps to the appropriate Flixu project and client profile, applying the correct Glossary and Brand Voice per application.
Connect your repository and run your first automated translation.
Install the GitHub App, configure your monitored paths, and push a commit. The first translation runs automatically — no dashboard step required.
Related Features
- Auto-Approval Workflows — LQA-based routing that enables zero-touch deployment
- LQA & Quality Assurance — The quality scoring that governs auto-approval decisions
- Translation Memory — How TM builds automatically with each approved commit
- AI Agents — Trigger translations from inside your AI coding assistant
- Developer API — Programmatic access for custom CI/CD integrations