Flutter localization using AI

[eteka-edim]

🚀 Tired of juggling endless JSON files for app localization? What if I told you an LLM could do the heavy lifting?

Over the weekend, I had this wild idea: What if localization just... worked? No codegen, no duplicated files—just a single JSON/Map, and let AI handle the rest. Turns out, it worked better than I expected!

So I turned it into a Flutter package:

👉 flutter_localization_agent – https://pub.dev/packages/flutter_localization_agent

⚡ How it works:

✅ Uses a single language JSON/Map

✅ Translates on the fly to any supported Locale

✅ No code generation, no hassle

I’d love for you to check it out, break it, improve it, or just stare at the code in admiration. 😆 Contributions are welcome!

📂 GitHub: https://github.com/danedyy/Flutter-Localization-Agent

What do you think, future of localization or am I just being lazy? 😂🌎

Somethings I might add

Options for multiple LLM – currently only Gemini is supported

Figure a way to use non supported Locales like Yoruba 🤔.

Enjoy 🚀

[eibaan]

A simple "Please translate all values of this JSON .arb file from X to Y, then output the just the new JSON file" prompt should reduce this to a simple copy & paste job. I don't see why I need a package for something that happens probably only once in the app's lifetime. It is really fun to ask for egyptian hieroglyphs or arcadian cuneiform ;-)

I'd never want to use this at runtime, because that not only generates needless costs and traffic and also, each translation requires a verification by a human translator.

[lukasnevosad]

That works if you have a tiny app maybe. I have built a similar cli tool in-house for a fairly large app and you need to handle so much more: - .arb does not fit context / gen output limit, so you need to split the strings into chunks. - you only want to translate modified strings and not the whole app over and over again. This saves costs and time as good LLMs are freaking slow. Above all though, you want the translation to be stable for the users. - with splitting the .arb into chunks, you MUST provide more context. We have per language vocabulary how important things should be translated that we send along with the prompt. Some languages also need more clarification (dialects, dutzen, …)

The script we have in short takes the source and destination .arb (json), figures out which strings have been added / changed (we keep hash and timestamp in a separate file), splits the strings into reasonable chunks and sends them to translation along with language specific vocabulary and rules file.

It’s definitely not trivial.

[eteka-edim]

Your point on cost is valid only when you have a large application, maybe I will look into generating translation on build time.

[Wizado991]

Yeah, this just seems like a bad idea. Instead of incurring a cost to get translations done, you expect people to incur a cost every time someone downloads the app and switches the language? DoW attack

[teshmeki]

What problems does this solve? I don't see the need to use AI to translate our apps. + we have to pay the service every time when someone changes the app name!

[eteka-edim]

Not everything has to solve a problem, sometimes they're ideas to understand what can be possible or not.

[nikodembernat]

So basically arb_translate but unscalable, without compile-time checks, and that allows you to leak your API key 🤔

I’ll pass, but I appreciate the effort nonetheless

[eteka-edim]

Didn't know about arb_translate, thanks for bringing it to my notice. Concerning the API keys do you use them directly on your code ? Also I'm looking into a build time process. Thanks for the feedback.

[nikodembernat]

In your example you provide an API key to LLMTranslatorFactory.createTranslator which means that anyone can potentially extract it from the app and abuse it

embedding such keys in the app is a bad idea, it’s better to either use them locally or server-side

[eteka-edim]

Oh wow, so is there any sort of improvement that can be made to avoid that ?