I've always found translation keys a little strange.

You start with something perfectly readable:

tsx <button>Delete account</button>

Then i18n turns it into something like:

tsx <button>{t("settings.account.delete")}</button>

Now the source code, translation keys, and translation files all have to stay synchronized.

So I tried a different approach with Zintl:

What if the source string itself could be the thing the localization system knows about?

With Zintl, you keep writing normal application code:

tsx <h1>Welcome back</h1> <p>Your account is ready.</p> <button>Continue</button>

Zintl's compiler discovers the localizable strings and builds the localization layer around them.

The goal is that adding i18n shouldn't mean rewriting your application around t() calls.

It's currently alpha, so I'm very much not claiming this is production-ready.

I'm looking for React developers who have actually dealt with i18n to try it and tell me where this approach falls apart.

Especially interested in:

• translation key management
• dynamic/interpolated strings
• component boundaries
• pluralization
• large applications
• translation workflows/TMS
• anything you think a compiler like this should handle

Docs: https://zintljs.github.io/zintl/en

I'd genuinely love the criticism. If you think the whole idea is flawed, tell me why.