Why GitHub Integration Changes Your Localization Workflow

Translation files belong in Git

Most developer teams already keep their translation files (JSON, YAML, PO files) inside their main repository. This is the right call: translations change with code, they should be versioned alongside it, and the same review process — pull requests, diffs, code review — applies.

But "files in Git" is a low bar. The bigger question is: how do changes actually get into those files?

The typical (painful) workflow

Without dedicated tooling, localization usually looks like this:

• A developer adds new UI strings and commits placeholder values in English.
• Someone exports the JSON files and emails them to a translator.
• The translator fills in values in a spreadsheet or text editor and sends them back.
• A developer manually merges the translated values back into the JSON files.
• This process repeats for every language, every release cycle.

This is slow, error-prone, and doesn't scale. Keys get missed. Merge conflicts happen. Translated strings end up out of sync with the code they belong to.

What GitHub integration actually changes

The key insight is that translation management should live next to the Git workflow, not separate from it.

When your translation tool connects directly to GitHub, the workflow becomes:

• A developer adds a new key in code and it automatically appears in the translation dashboard.
• Translators fill in values in a clean UI — no JSON editing required.
• When translations are ready, the tool opens a pull request against your repo with the updated files.
• The PR goes through your normal review process and gets merged like any other change.

No email. No manual merging. No out-of-sync files.

Branch-aware syncing

Good GitHub integration also understands branches. If your team uses feature branches, translation work should happen on the same branch the feature is being built on — not always on main.

This means translators can work on a feature's strings while the feature is still in development, and everything lands in the same PR. No last-minute scramble to add translations before a release.

Version control as an audit log

Another underrated benefit: because all translation changes go through pull requests, you get a free audit log. You can see exactly what changed, when, and why — the same way you track code changes. If a translated string introduces a bug or incorrect terminology, you can trace it back and revert it in seconds.

Setting it up with Locly

Locly connects to your GitHub repository in a few clicks via OAuth. Once connected, it reads your translation files, shows you a dashboard of all your keys and languages, and writes changes back as PRs.

You don't change how your app loads translations — your code still reads the same JSON/YAML files it always did. Locly just makes keeping those files up to date dramatically easier.

If you're managing more than one language and more than one person is involved in translations, GitHub integration isn't a nice-to-have. It's the thing that makes the whole process sustainable.