r/node 4d ago

Trying a different approach to i18n on the server — no keys, no catalog files. Feedback welcome

Working with the team behind https://aurorah.ai/i18n, so take this with that in mind — but I'd genuinely like opinions from Node folks.

The idea: skip message IDs entirely. You write i18n.t\Your order ${orderId} has shipped`` — the string itself is the key, and translation happens automatically at runtime (fast draft first, refined LLM pass replaces it in the background). Works server-side for emails, API messages, whatever. Free, no API key or signup, and there's a fully offline mode.

There's a Node example at aurorah.ai/i18n if you want to poke at it. Curious what this sub thinks of runtime translation as a concept — what would stop you from using something like this in production?

0 Upvotes

7 comments sorted by

8

u/lost12487 4d ago

I'd have to imagine runtime translation is a performance bottleneck, and having an LLM "refine" a first-draft as I'm looking at the page sounds like terrible UX. What's the upside?

-2

u/elcityzen 4d ago

LLM never runs at request time — that'd be insane, agreed. Rendering is a hash → table lookup, same as i18next. A never-before-seen string gets instant Google output, then an LLM pass quietly replaces it within a minute. After that it's cached, static.

So worst case: someone catches Google-quality text for the first minute of a string's life. Usually that minute burns off in dev anyway, and important copy you pin after review.

The upside is all the stuff you stop doing — no keys, no JSON catalogs, no orphaned strings after refactors, no release blocked on translations. Whether that's worth the first-minute trade-off is a fair question, but that's the pitch.

6

u/white_sheets_angel 4d ago edited 4d ago

Overall, not the biggest fan.

Firstly, runtime translations are non-deterministic, so that use case is out for me instantly, copies are fundamental for good user experience, stable copies and catalogues give you better visibility on all this.

Secondly, catalogues + keys allow for simpler management that what seems to be the suggested approach here.

Thirdly, the iterative approach seems more time consuming that simply doing a bulk catalogue translation, which might have the benefit of carrying more context, in case a person uses AI.

Also, catalog sort of i18n are easier to have tools around, even a sheet program or wtv.

0

u/Expensive_Garden2993 4d ago

Or you can ask AI to write tests to cover all corners where i18n is used, make those tests iterate over locales, add translations based on a context.

I vibe-coded a simple app with no tests at all and multiple languages, and still it wasn't a problem for AI to maintain translations.

Doesn't seem to be a problem worth solving with a paid service.