Automating i18n File Alignment with GitHub Actions

Hello, I am Maya from KINTO Technologies and today I’d like to quickly share a kaizen the Localization team implemented along with our Product Development team.
Keeping internationalization (i18n) files aligned across systems is a challenge every growing product faces. For our team, revising the data of a specific project, together with the development team revealed how quickly inconsistencies can sneak in, and how painful manual fixes can be.

The Problem

When working across multiple GitHub repositories, both teams discovered a mismatch in one of the i18n files we were relying on for a product. We huddled together one day and created a problem framing grid to visualize the issue to product managers and team leads alike in the hopes to gain support (which we quickly did!) so we could work on implementing a solution.

Category	Details
Who	The Product Developers and Localization team
What	We found that i18n file data diverged between GitHub and Lokalise
Where	Issues were detected in both GitHub repositories and Lokalise projects
When	During cross-checking of all i18n files for a certain product project
Why it matters	・Unnecessary or outdated data can accumulate. ・If left unresolved, the Single Source of Truth (SSOT) breaks down. ・Manual verification means going line by line, which is time-consuming and error-prone.

The Impact

By not having ways to detect data discrepancies, developers risk working with broken keys, outdated strings, or misaligned naming conventions. On the localization side, we sadly wasted effort working on content that did not exist in production.
We learned the hard way that these misalignments may seem so small and harmless at the beginning, but if left unchecked, could end up creating and accumulating unnecessary data that clutters the files and leads to inefficiency. This can also contribute to higher costs and cause inconsistent user experiences in the long run.

From Idea to Solution

We needed a way to automatically keep track of i18n files, detect changes in GitHub as soon as they occurred, and have an alert that lets us know (the Localization side) so we could work on reconciling differences between GitHub and Lokalise before the files drifted too far apart.

To achieve this, we built a GitHub Action that runs whenever a Pull Request (PR) touches any i18n file. The action inspects the files in the PR and, if changes are detected, sends an alert to a dedicated Slack channel. The Localization team is instantly notified and can decide whether a change is a legitimate key rename or removal, and whether the same update should be reflected in Lokalise.

This small automation keeps development and localization in sync and sparks quick conversations before issues pile up.

The following diagram illustrates how it works:

1. Repositories A to E each contain i18n files.
2. The GitHub Action monitors these files and triggers whenever a PR modifies one.
3. The Action sends an alert to a dedicated Slack channel we called #notice-localization-watcher.
4. The Localization team reviews and syncs updates with Lokalise if needed.

The alert looks like this and is sent to me, the Localization team and the Product Development team we added to the channel:

Benefits

Using GitHub Actions to watch i18n files turned a tedious manual job into a simple, scalable process. It’s already making work smoother and saving both teams time and effort. We accomplished:

• Faster detection of unnecessary data and avoiding surprises during cross-checks.
• Cleaner data, keeping GitHub and Lokalise in sync as a Single Source of Truth.
• Quicker team collaboration prompted by the alert, which allows us to do small check-ins via Slack between teams to check which data is needed and which isn't.

Drawbacks & Next Steps

Like any automation, it has its ups and downs. Although we haven't experienced it yet, frequent alerts could cause noise and fatigue, especially if every PR triggers a notification. Alerts also provide limited context as they flag that “something changed” but don’t show which keys were added, removed, or renamed at a glance unless you access the full PR. Without an even clearer way to define and maintain the source of truth, file drift can continue despite the above efforts.

To improve, we plan to add diff snippets to alerts so changes are immediately visible, and filter to focus on meaningful updates like key additions, deletions, or renames. Another idea is to batch alerts into daily or weekly summaries to reduce noise. We’re excited to see how these refinements make it even smoother!