Internationalization is Not About Translation: It's About Architecture

Most developers, especially front-end developers, believe they get internationalization because they know how to translate strings.

However, as Jan Amann put it on The Agile Localization Podcast, that belief is exactly the root problem. Internationalization is not translation; it’s product architecture.

It’s how you model language, market variants, currency, locale, routing, content pipelines, testing, layout impact, and performance before you even think about translation keys. That is the mental switch most developers never make and why so many multilingual projects fall apart as soon as you add the third language, the first regional variant, the first new market, or the first SEO requirements.

Jan has been thinking about this for half a decade. He’s the creator of next-intl (the internationalization library used by Ethereum’s website) and author of the i18n course for React/Next.js devs.

And he says that developer misconceptions are the #1 blocker to building apps that actually scale globally.

Listen to the new episode on:

Why Developers Misunderstand i18n Scope

Developers starting out believe internationalization means translating words. Jan literally wrote this as a headline in the next-intl documentation. Because it’s the single mental model that breaks everything.

Translation is a delivery mechanism. Internationalization is a design strategy. If you don’t architect the product for multilingual plus multiregional behavior before you translate a single string, you’re already building a legacy.

For example:

Canada: 2 native languages (English + French) for one country.
Austria: one native language (German), but people want English as UI too.
eCommerce in Europe: price, tax, shipping cost differences per country.

This is why Jan always forces developers to answer a binary question at the beginning:

Are you multilingual?
Are you multiregional?
Or both?

Most products are both, which is why i18n is a systems problem, not a dictionary problem.

Next.js Internationalization (i18n): Go International with next-intl

The Top Multilingual SEO Mistake Developers Make

When discussing the top mistakes developers make with multilingual SEO, Jan pointed to a foundational, yet frequently flawed, technical component.

"

There’s a good study on this from Ahrefs. They claim that, 67% of websites have problem with a concept that is referred to as hreflang.

The hreflang tag is important for SEO because it tells search engines, like Google, about the localized variants of a page you provide to users. It helps to show the correct language or regional version of a page is served in search results.

While the concept of simply listing all language variants seems easy on the surface, Jan notes that the nuance in the details is what ultimately trips up the majority of developers. Getting this wrong means search engines can’t properly index your international content, damaging your global visibility.

Ensuring correct hreflang implementation is one of the mandatory areas that must be covered to guarantee your site is part of the 33% who get it right.

The Killer Constraint Nobody Talks About

Performance is where most libraries cheat. Many i18n libraries split translations by message. And yes, that’s great for tree shaking.

However, Jan explains it creates a hidden problem: every language you add increases the runtime cost. That’s fine when you’re adding Spanish as your second language. What about when you’re adding your 60th?

Ethereum.org ships to approximately 67 languages. For them, the ”runtime cost scales with language count” is simply unacceptable. So next-intl takes a different stance:

Performance baseline stays flat.
Adding new languages does not degrade performance.

That design choice is the difference between a side project i18n setup and a global-scale i18n architecture.

How Ethereum.org Ensures Quality of Community Translations at Crowdin

Read here

Testing Is Where Most i18n Breaks

Jan’s UX background sneaks out here. He says a delightful multilingual UX is not bells and whistles, but the absence of annoyance. Annoyances are things like:

Broken layouts because German strings are too long
A UI that half appears in English and half appears in French
Currency symbols formatted incorrectly
Dates formatted wrong for the region

And no automated tooling will protect you by default.

Two testing non-negotiables from Jan:

Pseudo-localization.
Manual review with native speakers.

But how has the landscape changed with the arrival of generative AI?

What About AI?

Jan doesn’t sugarcoat it. AI changed everything, but it only changed translation, not internationalization. The real lever is automation, not “ChatGPT wrote my strings.”

The future workflow he outlines is:

Developers generate code, and translations are extracted automatically.
TMS, like Crowdin, handles context plus linguistic integrity.
CI pushes updated translation into the repo on every feature build.
Manual native review is still the quality gate.

"

The act of translating words and sentences and interfaces was certainly one of the areas which have been, like, very heavily changed by artificial intelligence, by generative AI. … I think Crowdin, for example, provides really helpful tools in this area. Like, for example, the Crowdin CLI, which helps you as a developer to upload and download translations quickly, and then also integrate it with your CI pipeline.

AI makes it faster to ship a multilingual product. But it doesn’t eliminate the need to architect a multilingual product. The danger is believing translation equals localization. That would be like believing turning on HTTPS equals “we have security.”

The Golden Rule

Jan summarized the entire philosophy with one line: “The goal is for your users to feel at home.”

Internationalization is hospitality. If someone arrives in your digital room, and nothing is for them, no language, no currency, no cultural alignment, they will bounce.

But if they arrive and everything feels native, they stay, buy, and trust.

Final Thoughts From Jan

Jan’s course is basically the field guide he wishes existed before he spent 5 years answering developer DMs about i18n mistakes. And the fact that senior devs who had been using next-intl for years still learned dozens of new things from it. That tells you where the real complexity is.

Internationalization is not translation. It is architecture. If you want to build global products that scale beyond the first two languages, start here.

Jan’s Background

Jan Amann is an independent internationalization expert and freelance developer based in Austria, best known for creating next-intl, an open-source internationalization library for Next.js, and developing a comprehensive online course on internationalization development. With five years of hands-on experience building multilingual applications and consulting with developers across the globe, he brings deep technical expertise in solving real-world localization challenges.