Ollang DX

The AI Language Execution Layer for Enterprise

API

Developer Tools

Artificial Intelligence

Very useful service. We actually have a project that we want to translate into the top 10 main languages.

By the way, how is your quality for translating less common languages? For example, Swedish? Most services usually struggle with that...

An language execution layer sitting between enterprise systems and AI models is an interesting architectural bet. Would want to understand how it handles latency at scale - most "AI layer for enterprise" things work fine in demos and then fall apart when you actually route production traffic through them.

If I want to make my app available in whatever language users want, is this something Ollang can help with? I've noticed llms are good at some languages, and less fluent in others, which can make for a non-uniform experience for users

Long time Ollang user! Congrats on the launch @mazula95 !

I’m curious, how do you handle iteration and feedback loops? Like when translations get revised multiple times (by PMs, local teams, etc.), does the agent learn from those edits over time or is each run stateless?

the "english-first by default" framing is spot on. every ai workflow i've seen just assumes english and offloads the rest to a separate team or pipeline.

curious how the SKILLS layer works in practice across different agents, is it framework-agnostic or does each one need its own wrapper?

So proud of you for shipping this! 🎉 Honestly, it is such a clever move. To answer your questions: Cursor and Claude Code are definitely the most critical agent integrations for my workflow right now. As for file types, handling JSON for i18n directly within the workflow without breaking the structure is a lifesaver. Congratulations! 🚀

Love this! feels like something that should’ve existed already.

Curious about one thing: how do you handle quality consistency across very different modalities (e.g., subtitles vs. dubbed audio vs. structured JSON)? Is there a shared evaluation/QC layer, or does it vary per file type?

Localization is one of those things that gets shoved to the end of every sprint and done badly. The MCP + SKILLS approach for agent-driven workflows is interesting - what does a typical localization workflow look like when the agent runs it end-to-end? I'm curious how it handles context (strings that need different translations depending on UI placement) vs just raw key-value substitution.

Localization is one of those things that always gets pushed to "later" and then becomes a nightmare when you finally need it. How does it handle context-dependent translations? Like in our app, the word "network" means something very specific - does it learn domain-specific terminology or do you need to manually define a glossary?

This is exactly the kind of product that makes you think 'why didn't this exist before?' Multimodal localization with MCP + Skills + SDK in one platform is genuinely elegant architecture. The developer experience looks clean, and the enterprise angle is well thought out. Congrats on the launch @mazula95 — the future of AI-native localization is in good hands. 🚀

Congrats on the launch, Aziz!

Localization has always been one of those things that feels like it should be a one-liner but ends up being 5 different tools duct-taped together. Can't wait to finally having something work natively inside agent workflows instead of as a separate step is a big deal! Nice work 🚀

Hey Product Hunt 👋

AI agents are everywhere, but localization is still fragmented, manual, and painfully multi-step.

We built Ollang MCP, Skills, and SDK to fix that.

→ One API to localize any file type
→ Works directly inside your agent workflows
→ Built for real-world complexity (video, audio, docs, i18n — all in one flow)

Curious, what’s the most painful part of localization in your current stack?