If you've ever built a multilingual application, you've probably started with something like this:
{"welcome":"Welcome","logout":"Logout"}A few weeks later you add another language:
{"welcome":"Witamy","logout":"Wyloguj"}Everything still looks manageable.
Then the product grows.
More features are added.
More developers join.
More languages appear.
Suddenly your repository contains:
locales/
├── en.json
├── pl.json
├── de.json
├── fr.json
├── es.json
├── it.json
└── ...
And that's when localization starts becoming a maintenance problem rather than a translation problem.
The Hidden Cost of Translation Files
Most teams focus on translating text.
In practice, the harder problem is keeping translations synchronized.
Questions start appearing:
- Which keys are missing in German?
- Which translations are outdated?
- Which strings were recently changed?
- Why is production showing a fallback language?
- Which developer forgot to update all language files?
The larger the application becomes, the harder these questions are to answer.
Git Was Never Designed for Localization Workflows
Git is excellent for source code.
It is much less effective for managing hundreds or thousands of translations.
Imagine changing:
{"subscription_expired_message":"Your subscription has expired"}Now that same change needs to be reflected across:
- Polish
- German
- French
- Spanish
- Italian
And every translation file must stay synchronized.
Developers often end up spending more time managing translation files than writing features.
AI Makes Translation Easier, But Doesn't Solve Management
Today we can generate translations using:
- OpenAI
- DeepL
- Google Translate
Generating translations is easy.
Managing them is still difficult.
You still need to:
- store them
- version them
- review them
- serve them efficiently
- keep languages synchronized
AI solves translation generation.
It doesn't solve translation infrastructure.
What Changed My Approach
Instead of treating translations as files, I started treating them as data.
The workflow became:
- Store translations in a centralized system.
- Manage translation keys through an API.
- Generate missing translations automatically.
- Serve translations through cached endpoints.
- Keep source code focused on business logic.
Instead of:
Git Repository
└── Translation Files
The architecture becomes:
Application
↓
Translation API
↓
Translation Store
↓
AI Translation Providers
Benefits
Easier Collaboration
Developers, translators, and product owners can work independently.
Better Visibility
You can immediately see:
- missing translations
- outdated strings
- approval status
Faster Releases
Adding a new language no longer requires editing dozens of files.
Reduced Merge Conflicts
Translation changes stop polluting source control.
Is File-Based Localization Always Wrong?
No.
For small projects, translation files are perfectly fine.
If your application has:
- one developer
- two languages
- a few dozen strings
there is little reason to introduce additional infrastructure.
But once localization becomes an ongoing process, centralization starts paying off quickly.
Final Thoughts
Localization is often treated as a translation problem.
In my experience it's actually a workflow problem.
The challenge isn't generating text.
The challenge is managing thousands of translations across multiple languages while keeping development fast and predictable.
The earlier you solve the workflow problem, the easier localization becomes as your application grows.
How are you managing translations today?
Still using JSON files in Git, or have you moved to a centralized localization workflow?
I'm currently building i18nme.com, a localization backend for developers. Building it forced me to rethink how translation workflows should work at scale.
For further actions, you may consider blocking this person and/or reporting abuse
