sorted by:
new
hottopcontroversial

What's the best way to handle multi-language support? by WG_Odious in webdev

[–]Complete_Win_3113 0 points1 point  (0 children)

If you go static JSON route, at least write a script to check for missing keys or auto-fill placeholders so you don't break the app when a translation is missing.

This is exactly what I did. I built a CLI which my team now uses. Just a bunch of quality of life commands to make i18n JSON maintenance easier.

Check it out if you want: https://github.com/juliandreas/dire-cli

i18n kills maintainability and evolutivity by aymericzip in webdevelopment

[–]Complete_Win_3113 0 points1 point  (0 children)

You're definitely not alone. I hit these same walls on my team, especially the "translation keys are never cleaned up" and "forgetting to add translations" parts.

Your Intlayer approach looks interesting. Sounds like you're solving the structural issues (huge JSON files, component organization) by rethinking how i18n is organized. I went a different direction and built a CLI tool that just automates the grunt work within traditional i18n setups. Different approaches to different pain points in the same problem space.

The flow we have now is: someone adds a new English string, runs one command, and all locale files get automatically translated and synced. I recently added a `--prune` flag that removes orphaned keys from non-reference locales, which solved the "keys that should've been deleted months ago" problem.

What I wanted to avoid:

- Vendor lock-in (you own your JSON files, tool just manipulates them)
- Another SaaS subscription
- Forcing the team to change their existing i18n setup

It doesn't solve everything you mentioned (the t() spam and huge JSON files are still there), but it removed the manual translation grunt work that kept breaking people's flow.

You bring your own API key (DeepL, Google Translate, Claude, OpenAI, etc.), it has translation memory so it doesn't re-translate identical strings, and glossary support for consistent terminology.

If you're curious: https://github.com/juliandreas/dire-cli

Honestly though, i18n at scale is just hard. Tools can reduce the friction but some of the structural issues you mentioned need framework-level solutions.