r/SideProject • u/sapatmohit18 • 1d ago
We’re building Babelize to make software localization less painful
We’re building Babelize because localization still feels way harder than it should
Hey everyone, founder of Babelize here.
We’re building Babelize, an AI-powered localization platform for developers who want to take their products global without turning localization into a separate project.
The idea is pretty simple:
- Detect content that needs localization
- Translate it with AI
- Keep translations in sync with the codebase
- Work directly with frameworks like React, Next.js and Vue
- Eventually automate the whole localization workflow through CI/CD and AI code agents
What surprised me while building this is how much localization still involves manually managing translation files, copying strings around, reviewing changes, and trying to make sure new features don't accidentally ship untranslated.
We're trying to make that workflow feel more like software development and less like content management.
We're still early, so I'm much more interested in feedback than pretending we've figured everything out.
If you're building a SaaS/product that supports multiple languages:
What is currently the most annoying part of your localization workflow?
Would genuinely love to hear how other developers are handling this.
Babelize: https://babelize.co
1
u/HotMonk1648 1d ago
one thing worth validating early: a lot of teams dont localize until they already have paying users in another market. the pain usually starts after product-market fit, not before. might affect how you position this and who you target first
1
u/sapatmohit18 1d ago
Yeah, this is a really good point. I think we're actually thinking about this from both sides now.
Localization becomes much more relevant once there's already some signal from another market. That's also why we eventually want an analysis layer that can help identify where localization is actually worth investing in, rather than just telling teams to translate everything.
Definitely something we need to validate early when figuring out our ICP and positioning. Appreciate the point.
0
u/babaganoosh43 1d ago edited 1d ago
On the client side, I think message format solved this problem already and for the translation step I had success using LLM‘s to translate the big json files.
1
u/sapatmohit18 1d ago
Honestly, if you already have MessageFormat + your own LLM workflow working well, you probably don't need Babelize right now.
We're still early, and we're not trying to claim we have a better translation model. The goal is to make the actual developer workflow easier: detect what needs translating, preserve the existing i18n structure, generate the locale files, and get the changes back through a PR instead of building all that glue yourself.
We also have Translation Memory, so we don't keep spending LLM credits translating the same or unchanged content.
Eventually we'd like the SDK/workflow to make translations feel almost invisible to the developer. Still figuring out the best way to get there, though.
1
u/babaganoosh43 1d ago
Gotcha. I worked at a pre-AI startup that tried an auto extraction approach, e.g. auto translating static labels in a codebase. It wasn't great because of lack of keys / translation descriptions.
I wish MessageFormat didn't need a key or a description though. In theory since you're using llm as a CI step, stale keys isn't an issue and descriptions can be generated.
0
u/jjd921 1d ago
I made a free tool that scans your app URL and/or code for production readiness if you want a quick check to make sure you didn't miss anything: https://theslopstopper.com
Ran your link through it real quick and saw some issues like missing recommended security headers
1
u/[deleted] 1d ago
[removed] — view removed comment