u/shakshukinha

Hi,

I'm building intl-ai and I'm looking for feedback.

I've been looking into localization (i18n) lately, and I noticed something interesting: looking at highly successful dev-focused products like emdash.sh or charm.land, you see they have massive engineering reach and beautiful UIs, yet both support only English.

If top-tier developers aren't localizing, it’s not an expertise gap. It’s a tooling gap.

As devs, we all know the traditional i18n workflow is a massive headache:

• Juggling massive, nested .json files.
• Dealing with missing keys, broken interpolations, or manually syncing translation files.
• Relying on manual translator handoffs or clunky localization dashboards that don't fit into our git workflow.
• Incurring massive technical debt just to add a single feature because you have to update 5 different language files.

Even with current AI tools, the process isn't automated natively at the build layer. It still requires manual copying/pasting or running disconnected scripts that require constant human review.

I got tired of this workflow, so I’ve been building intl-ai to treat translations like a compiled asset rather than a manual chore.

The idea is simple: you wire it directly into your existing i18n setup and build tool (supports NextJS, Vite, and mobile), configure your preferred LLM model, and it automatically handles the localized string generations in an instant during your build or CI/CD pipeline. No more manual JSON synchronization or fragmented developer experiences.

I’m looking for some feedback from anyone who actively deals with (or avoids) i18n in their current stack. How are you handling translations today, and what’s your biggest bottleneck?

Check out the docs to get quickstarted https://intl-ai.pages.dev , or just share it with your agent https://intl-ai.pages.dev/llms.txt .

Hey fellow founders,

I'm building intl-ai, an open-source translation tool and want to get your feedback on it.

We all know that landing pages need high visibility to maximize our acquisition funnels. But look at breakout indie products like https://distill.id/ or https://recollect.so/. They already have a strong user base and great growth, yet they only support English.

When you're a solo founder or a small team, you usually skip localization. Not because you don't want international users, but because traditional localization (i18n) takes too much time, costs too much money, and introduces massive maintenance overhead.

But by staying English-only, we are ignoring some massive growth levers. If you look at the macro SaaS data:

• TAM Expansion: Over 70% of global internet users prefer browsing and buying in their native language. By staying English-only, you are actively locking out a massive chunk of your potential market.
• Conversion Rate (CR) Boost: Localizing just your landing page and checkout funnel can increase non-English traffic conversion rates by 20% to 40%.
• Reduced Churn: Users who onboard in their native language experience a faster "Aha! moment," leading to better early retention metrics.

The problem isn't that founders don't want these KPIs, but rather that the tooling gap makes it unviable. Traditional localization management software is expensive, and waiting on manual translation reviews slows down shipping speeds.

That’s exactly why I’m building intl-ai.

I wanted a way to get the benefits of global localization without the operational drag. It plugs right into your existing NextJS, Vite, or mobile codebase. You just hook it up to an AI model, and it handles your translations instantly inside your existing build pipeline.

If you've been putting off localization because of the technical debt or time commitment, I’d love for you to try it out and let me know if it solves the bottleneck for you: https://intl-ai.pages.dev , and https://github.com/sigilco/intl-ai on GitHub. Open Source, Apache 2.0.

What’s currently stopping you from localizing your SaaS? Is it the coding overhead or the fear of bad translations? Let’s talk.

Hi! I'm a hobbyist Codex user and lately I'm discouraged by the unequal support in the community to extra harness functionality like:

• Reduced token usage (think snip, rtk, etc.)
• Multi-agent orchestration tooling (think Claude's team mode)
• Long-running, auto-improving workflows (think Karpathy's autoresearch)

Then I realised it's not because of a lack of support from Codex but rather that every harness nowadays use a different plugin architecture. That's why I built AgentPlugins: write a plugin once, ship it to any harness. It's now live at https://github.com/sigilco/agentplugins ; Apache-2.0, open source. The approach is simple:

• One manifest: a compiler routes it to harness-native primitives (skills, agents, hooks, commands) per target, and emits a warning if a capability doesn't exist on a given harness instead of silently breaking
• Built-in compatibility for the most used agents (Claude Code, Codex, OpenCode, Pi) and community support for any other (Copilot, Gemini, Kimi, you name it)
• Easy to install, test, and distribute

For instance, to install Karpathy's autoresearch from https://github.com/sigilco/agentplugins-autoresearch just do:

npx @agentplugins/cli add https://github.com/sigilco/agentplugins-autoresearch

I'm mainly here for feedback. If you maintain plugins/skills across more than one harness (or gave up and just picked one), I want to know:

• Does "write once" match your actual pain, or is there a gap I'm missing?
• Do you miss built-in compatibility for any other harness?
• What would make you NOT trust a compiler layer sitting between your plugin and your agent?

Happy to answer anything in the thread.

Hi! I'm a seasoned OpenCode user and lately I'm discouraged by the unequal support in the community to extra harness functionality like:

• Reduced token usage (think snip, rtk, etc.)
• Multi-agent orchestration tooling (think Claude's team mode)
• Long-running, auto-improving workflows (think Karpathy's autoresearch)

Then I realised it's not because a lack of support from OpenCode but rather that every harness nowadays use a different plugin architecture. That's why I built AgentPlugins: write a plugin once, ship it to any harness. Live at https://agentplugins.pages.dev/ , Apache-2.0, open source. The approach is simple:

• One manifest: a compiler routes it to harness-native primitives (skills, agents, hooks, commands) per target, and emits a warning if a capability doesn't exist on a given harness instead of silently breaking
• Built-in compatibility for the most used agents (Claude Code, Codex, OpenCode, Pi) and community support for any other (Copilot, Gemini, Kimi, you name it)
• Easy to install, test, and distribute

For instance, to install Karpathy's autoresearch from https://github.com/sigilco/agentplugins-autoresearch just do:

npx @agentplugins/cli add https://github.com/sigilco/agentplugins-autoresearch

I'm mainly here for feedback, not a sales pitch. If you maintain plugins/skills across more than one harness (or gave up and just picked one), I want to know:

• Does "write once" match your actual pain, or is there a gap I'm missing?
• Do you miss built-in compatibility for any other harness?
• What would make you NOT trust a compiler layer sitting between your plugin and your agent?

Happy to answer anything in the thread.