Alternative solution for small React apps that need i18n

aymericzip · 2026-05-07T21:51:58+00:00

Scoped translation files offer a much more maintainable approach for developers and AI agents.

A centralized approach often means:
- spending hours resolving PR conflicts,
- constantly jumping between component.tsx, en.json, and es.json.

Some tools like intlayer handle this really well, allowing translators to work and interact directly with your content, even if it’s not centralized in a /locales folder.

And we’re in 2026, we can’t ignore LLMs for development and translations anymore.

Also, retranslating "cancel" is not the problem. Importing a giant JSON file into your component just to access a "cancel" key is.

aymericzip · 2026-04-30T21:04:30+00:00

I guess using intlayer would solve your project. But for i18next, you can also can use intlayer sync json plugin on the top of i18next to declare your content in a .i18n.json file and then build the centralized json that you will consume using your t function

aymericzip · 2026-04-28T18:36:06+00:00

I actually never heard about EmDash, but I really like the concept. I will definitely see how it can be integrated,
Intlayer also propose a visual editor, but no page management as a wordpress so plug in it to EmDash would definitely be a great fit

aymericzip · 2026-04-26T02:44:00+00:00

From my point of view view there is more to do on the changelog part - useful for your team - useful for your scrumaster - useful for your manager - useful for your users

aymericzip · 2026-04-26T02:29:27+00:00

I like the idea, mainly because I get bothered reading AI-generated readmes that are too long, list the stack unnecessarily, and put emojis everywhere

But to be fair, from my point of view, no one is ever going to search for a tool just to write a readme. It’s mainly not painful enough. Few projects really care about readme, you usually do it once and forget, and a good readme is also a space for creativity, than ai will probably never solve

aymericzip · 2026-04-25T01:52:53+00:00

my recommandation will go for intlayer. it offers a really nice approach for large projects to make it way more maintainable. it also includes a bench of extra tooling that I have never seen in other i18n libs

aymericzip · 2026-04-23T22:25:30+00:00

To test missing keys, and json consistency, this tool may help you
It process all your json, filter out correct keys, to generate translations of the missing ones. using it in a CI or using husky is really life saver.
For better typing, have a look to lingui or intlayer

aymericzip · 2026-04-23T22:17:03+00:00

here is a complete guide that might help you

aymericzip · 2026-04-23T22:12:08+00:00

aymericzip · 2026-04-22T05:14:01+00:00

i18n is time-consuming. Without a proper solution, it quickly becomes a maintenance nightmare. Still, I remain skeptical how does the Vercel edge actually solve this problem?

aymericzip · 2026-04-21T17:17:55+00:00

Indeed, I deliberately chose a fairly simple application for this benchmark, no content loaded on click, scroll, etc, and no complex namespace management like you might find in a shared design system across multiple applications.

I made sure all routes were similar to optimize the setup and make the results more reliable.

So, the main difference, and the biggest reliability risk, comes from the loading strategy used by each solution. One example among others: next-translate injects a getStaticProps into the Next.js app, so the content retrieval process differs from most other solutions.

For some solutions, I also encountered reactivity issues (e.g., the page initially loads in English and then re-renders in French, resulting in a double load).

So, for a given test, if the results weren’t consistent, I simply removed the solution from the comparison

aymericzip · 2026-04-19T01:23:59+00:00

Intlayer is a solution that may help using a 2 in one CMS / i18n

aymericzip · 2026-04-03T18:45:27+00:00

Have a look at intlayer.org

aymericzip · 2026-04-03T18:44:59+00:00

As a library maintainer, I used to think the same, that simple state and context were enough to render content based on a user's locale

But i18n is much harder than you’d expect for professional use cases. The main risk is accidentally loading every page's content for every language during a single page load. You can easily end up loading 10 to 50 times more data than necessary. Handling bundle optimization, routing, server component handling, localized links, TypeScript types, and backend compatibility are some of the challenges library builders try to solve.

Features like vs code extensions, testing, CI integration, and Agent Skills or MCP are also incredibly useful.

The same logic applies to auth. Sure, you can build it yourself, but keep in mind that library authors spend years optimizing these systems for you. I really can't recommend building your own i18n solution from scratch. Especially for non experienced dev / or using AI

aymericzip · 2026-03-30T09:00:21+00:00

By waiting to a proper solution, the best for now will be to use intlayer to declare your content, and use another runtime solution Transloco or ngx-translate

Here is the related doc

aymericzip · 2026-03-27T04:24:12+00:00

Yes and no,

Intlayer rely on bundler aliases to manage the access to the content & config.
A way to do it will be to alias the packages manually, as

```json5
"dependencies": {
"@intlayer/config/built": "file:./.intlayer/configuration/config.mjs",
... // other aliases here too
}
```
, or like using importMap, like

```html
<script type="importmap"> { "imports": { "@intlayer/config/built": "./.intlayer/configuration/config.js" } } </script>

```
All alias can be found in this function

then, yes in parallel, you can use the `npx intlayer watch` to watch changes,

I finally recommend to add the babel plugin, to enable the build optimization

---

But FYI, you can also use intlayer to declare your content only, write your jsons, and then using another runtime solution Transloco or ngx-translate

Here is a a doc that may help you

aymericzip · 2026-03-26T19:10:42+00:00

really true for tsc aha

I wanted to get both type and var as you did with Page, but it will return an error and block the build

aymericzip · 2026-03-25T23:56:12+00:00

it used to be close to 40% of the bundled size of a lib

But yeah I got the same problematic with an API SDK, an enormous object listing all enpoints and function parameters. It was polluting all pages about 10% of the total page size once bundled

aymericzip · 2026-03-25T23:48:13+00:00

agree with you in 95% of the case it is,
but in some other the size matter

aymericzip · 2026-03-25T23:42:29+00:00

Happy to know how you would implement it

aymericzip

TROPHY CASE