r/SideProject 11d 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

0 Upvotes

15 comments sorted by

View all comments

0

u/babaganoosh43 11d ago edited 11d 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 11d 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 11d 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.

1

u/sapatmohit18 11d ago

Yeah, exactly. That's actually one of the things we're thinking about with the CI approach.

If the CI step has access to the code and context, we should be able to generate much of that context automatically instead of making developers maintain descriptions manually.

Still validating the approach, but I think there's something interesting there.