🌀 Why Flutter Localization Is Still a Pain (Even With easy_localization) — and How I Finally Fixed It

Localization in Flutter sounds simple on paper:

“Just use ARB files, run the generator, and you’re done.”

Right?

Right… until your app grows to hundreds of keys, multiple languages, different plural forms, nested folders, and a team of devs all touching the same translations.

I’ve been there.
And after a few years of building multilingual Flutter apps, I’m convinced of one thing:

Localization is one of the most annoying parts of Flutter development.

Even with tools like easy_localization helping us generate code and structure files, there are still several pain points that never went away for me.

So I built a tool to fix them — but let me start with the problems first.

❌ Problem 1: ARB/JSON files don’t scale

JSON files are fine when you have:

title: “Hello”
button_ok: “OK”
button_cancel: “Cancel”

But with real apps, things turn into this:

settings.notifications.push_title
settings.notifications.push_body
profile.followers_count
profile.following_count
auth.password.strength.weak
auth.password.strength.strong

There’s no:

• tree
• grouping
• drag & drop
• visual structure Just nested dot-notation that you hope nobody mistypes.

It gets worse when:

• you want to rename a key
• move keys into a different namespace
• or just find things visually

How LokiLoki solves it

LokiLoki uses a real tree editor, like you'd expect in VS Code:

• folder hierarchy
• drag & drop
• instant type conversion (text/gender/plural)
• inline editing
• descriptions for translators

You can finally reorganize translations like a normal project.

❌ Problem 2: “Missing translations” is a scavenger hunt

easy_localization gives you warnings if you forget a key, but:

it won’t tell you where the missing key is in your files
it won’t show you which locales are incomplete
it won’t highlight partially filled languages
So what do we do?

We grep, scroll, search manually, compare files in diff-tools, or write small scripts to check for empty values.

How LokiLoki solves it

With one click, LokiLoki shows:

• empty keys
• partially filled keys
• fully translated keys
• structured by folders

And AI can fill missing ones automatically if you want.

❌ Problem 3: String literals in Dart code get forgotten

We’ve all done it:

Text("Retry")

App works in English.
You ship it.
And a month later someone asks:

“Why is this screen not translated?”

easy_localization can’t detect raw strings in your Dart code.
It also can’t suggest keys, infer context, or help you clean up legacy codebases.

How LokiLoki solves it

LokiLoki has a full Dart AST analyzer.

It finds:

• every .tr() call
• every plural()
• every LocaleKeys.something

and every raw string literal worth translating

Then AI can:

• propose a key
• generate a translation
• suggest replacing the literal in code

The “auto-localize” workflow is shockingly effective for large apps.

❌ Problem 4: Mistakes in JSON files break the entire project

One wrong comma, wrong nested object, or broken plural structure =
flutter pub run … generate explodes.

How LokiLoki solves it

It uses a patch panel where everything is validated before writing:

• rename keys safely
• move folders
• change types
• see diffs
• undo/redo
• apply as atomic patch

No more broken localization files.

❌ Problem 5: No way to understand global language coverage

If you have:

English
Spanish
Japanese
Chinese

…what percentage of the planet can actually use your app?

easy_localization doesn’t tell you.
Google Sheets doesn’t tell you.
You need population + language distribution data.

How LokiLoki solves it

LokiLoki has a World Coverage Map:

• see which languages cover which countries
• see global user coverage (%)
• regional variants are supported (e.g., pt-BR vs pt-PT)
• add languages with one click

You finally get data-driven localization.

❌ Problem 6: teams struggle to keep translation files in sync

Even with Git, merging JSON files is:

• noisy
• conflict-prone
• hard to review

And impossible to reason about when large refactors happen.

How LokiLoki solves it

LokiLoki baselines changes and shows them as readable operations:

• added keys
• removed keys
• renamed keys
• moved folders
• changed plural forms

All packaged into a clean patch you can review and apply.

🧰 So… what is LokiLoki exactly?

It’s a desktop app for Windows/macOS/Linux that wraps the entire localization workflow into one place:

Tree-based translation editor

Code usage analyzer

AI auto-localize

World coverage map

Patch system

Drag & drop key organization

Pretty JSON/YAML export

Supports easy_localization today (intl coming soon)

It started as a personal tool but grew into something I use on every project now.

🎁 Want to Try It?

Mine landing
The base app is free.
Only the code analyzer + AI features are premium. AI tokens is not free... (2 days free for test)

I’d love feedback — whether you're dealing with localization hell or just curious how this workflow feels compared to pure ARB editing.

Comments

[Sabenin Vladislav]

Honestly, I never planned to turn this into an actual tool — I just got tired of juggling JSON files and hoping I didn’t miss a key somewhere.
Especially once you have 6+ languages and someone on the team inevitably sneaks a hard-coded string into a widget 🙃

It started as a tiny script that just warned me about missing keys. Then I added a UI because editing JSON by hand was slowly killing me. Then I added code string detection… and you know how these side projects go — suddenly it’s a full product.

So if anything in LokiLoki feels like “why is it done this way?” — it’s probably because I was fixing a real pain point first and worrying about perfect UX later. I literally use this tool every day, and I’m polishing it step by step.

If anyone gives it a try, let me know what breaks first. That’s usually the most valuable feedback 😅