18ways blog
An AI-native way to do i18n in Next.js, without breaking SEO.
Internationalisation (often shortened to i18n), localisation (l10n), and multilingual support all describe the same idea: adapting your product so people can use it in their own language.
They also all share the same age-old problem. Every business eventually realises they need to support languages other than their native one. At that point, the engineering team sucks through their teeth like a mechanic, “How many pages do we need to translate? That’ll set you back at least 4 sprints.”
The underlying way we implement i18n hasn’t changed in 20 years. Most i18n “best practices” were formed long before modern web architectures, and everything since has simply been layered on top of them.
I18n is the only part of modern web development that still involves exporting files and sending them to someone. It’s considered a modern set up if instead of emailing them, you upload them through an API.
In a world of CI pipelines and deploys measured in minutes instead of days, we should probably count ourselves lucky we don’t have to fax anything.
Modern web development has moved incredibly quickly.
We have:
Yet internationalisation workflows still feel like they belong to a different era.
Even relatively small applications quickly end up juggling:
Developers don’t set out to build systems like this. They come stumbling into it, as common i18n hurdles trip up developers unfamiliar with how different languages structure sentences completely differently… and reluctantly accept the status quo set 20 years ago.
Over time, internationalisation becomes one of the most complex parts of the stack.
Consider a simple UI:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>This is easy to understand. It is simple.
At some point we decide to internationalise it. So, we extract the text into a translation file:
{
"mainPage": {
"greeting": "Hello world",
"cta": "<0>Click here</0> to view your <1>{{description}}</1>"
}
}And we reference that in our code:
<h1>{t('mainPage.greeting')}</h1>
<p>
<Trans key="mainPage.cta">
<a href="#/">Click here</a> to view your <b>{{ description: serverResponse
But, wait, we now have English text both in our code, and in our translation file? Yes. Different i18n libraries put different paint on it, but trying to translate text that is partially formatted by pulling it out into a human-readable JSON file is a losing battle.
Modern UI is structured, but translation systems are built upon the foundation of flat strings.
Once markup, variables, and dynamic content enter the picture, the abstraction starts to leak.
Things get even harder when content is not static.
Take this example again:
<b>{serverResponse.productDescription}</b>That string is coming from an API. How do we turn that into a translation key?
Spoiler: you don’t. Now your backend needs to support internationalisation too.
Your backend must now manage:
Translators suddenly need access to backend systems as well.
And the problem only grows when user-generated content enters the picture.
Reviews. Comments. Marketplace listings. Forums.
Traditional i18n pipelines assume that developers control all the text. Increasingly, that simply is not true.
The fact that companies like Amazon have begun experimenting with translated user reviews in 2026 says a lot about how slowly the i18n ecosystem has evolved.
Even determining which language a user wants is surprisingly complicated.
Browsers send language preferences through the Accept-Language header:
Accept-Language: en-GB,en;q=0.9,fr;q=0.8This tells the server:
In practice, implementing this properly involves:
en, en-GB, en-US)Many frameworks leave most of this logic up to developers.
Even basic locale detection often becomes custom application code.
Translation infrastructure is only half the problem.
Users still need a way to change languages.
Most i18n libraries provide the translation layer but leave the rest of the problem to the developer:
hreflang tags for SEOThese details sound small, but they quickly become a significant amount of application plumbing, especially if you’re not familiar with all the intricacies of i18n. Most companies and developers are not.
Given all of this complexity, some teams turn to automatic website translation tools. These platforms promise to translate your site automatically with minimal effort.
Several companies are building increasingly sophisticated versions of this idea. Unfortunately they introduce a different set of problems:
The result is often a site that technically supports multiple languages but delivers a noticeably worse experience, and is a black box for developers to work with.
We started with something beautifully simple:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>And ended up with translation keys, JSON dictionaries, fractured pipelines, separated backend and frontend localisation layers, and external translation tooling.
Modern web apps are incredibly sophisticated systems. Yet, i18n tooling expects workflows designed for a different era, like a Ferrari with a hand crank to start the engine.
What if internationalisation looked more like this?
<h1><T>Hello world!</T></h1>
<p>
<T>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</T
No translation keys.
No JSON dictionaries.
No manual pipelines.
Just text.
This idea is the foundation behind 18ways.
18ways treats translation as an optimised runtime concern. Extracting translation keys and managing translation files is a problem for machines, not humans.
Developers simply mark the text they want translated.
Behind the scenes, 18ways:
Everything remains SSR-friendly and SEO-safe.
Traditional i18n systems lose context.
A translator might see something like:
homeBut what does that mean?
In German, these meanings require completely different words:
Haus - a houseStartseite - the homepageStart - a navigation labelzum Anfang - return to the beginningTranslation systems that only see isolated strings struggle with these distinctions.
18ways analyses translations in the context of the actual UI.
Our backend agents review translations as they appear on real pages and optimise for:
Overflow detection is included too - looking at you, German compound nouns.
Everything that helps AI produce better translations also helps human translators.
18ways provides translators with the same context-aware environment our AI agents use.
Instead of editing JSON files, translators review text directly against the UI where it appears.
This dramatically improves translation accuracy and workflow efficiency.
Internationalisation does not need another layer of translation keys, string files, and pipeline glue.
Modern applications already have the structure, context, and runtime information we need to do this better.
The next generation of i18n should be built for server-rendered apps, dynamic content, AI-native workflows, and human translators working side by side.
That is the direction 18ways is taking.
18ways blog
An AI-native way to do i18n in Next.js, without breaking SEO.
Internationalisation (often shortened to i18n), localisation (l10n), and multilingual support all describe the same idea: adapting your product so people can use it in their own language.
They also all share the same age-old problem. Every business eventually realises they need to support languages other than their native one. At that point, the engineering team sucks through their teeth like a mechanic, “How many pages do we need to translate? That’ll set you back at least 4 sprints.”
The underlying way we implement i18n hasn’t changed in 20 years. Most i18n “best practices” were formed long before modern web architectures, and everything since has simply been layered on top of them.
I18n is the only part of modern web development that still involves exporting files and sending them to someone. It’s considered a modern set up if instead of emailing them, you upload them through an API.
In a world of CI pipelines and deploys measured in minutes instead of days, we should probably count ourselves lucky we don’t have to fax anything.
Modern web development has moved incredibly quickly.
We have:
Yet internationalisation workflows still feel like they belong to a different era.
Even relatively small applications quickly end up juggling:
Developers don’t set out to build systems like this. They come stumbling into it, as common i18n hurdles trip up developers unfamiliar with how different languages structure sentences completely differently… and reluctantly accept the status quo set 20 years ago.
Over time, internationalisation becomes one of the most complex parts of the stack.
Consider a simple UI:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>This is easy to understand. It is simple.
At some point we decide to internationalise it. So, we extract the text into a translation file:
{
"mainPage": {
"greeting": "Hello world",
"cta": "<0>Click here</0> to view your <1>{{description}}</1>"
}
}And we reference that in our code:
<h1>{t('mainPage.greeting')}</h1>
<p>
<Trans key="mainPage.cta">
<a href="#/">Click here</a> to view your <b>{{ description: serverResponse
But, wait, we now have English text both in our code, and in our translation file? Yes. Different i18n libraries put different paint on it, but trying to translate text that is partially formatted by pulling it out into a human-readable JSON file is a losing battle.
Modern UI is structured, but translation systems are built upon the foundation of flat strings.
Once markup, variables, and dynamic content enter the picture, the abstraction starts to leak.
Things get even harder when content is not static.
Take this example again:
<b>{serverResponse.productDescription}</b>That string is coming from an API. How do we turn that into a translation key?
Spoiler: you don’t. Now your backend needs to support internationalisation too.
Your backend must now manage:
Translators suddenly need access to backend systems as well.
And the problem only grows when user-generated content enters the picture.
Reviews. Comments. Marketplace listings. Forums.
Traditional i18n pipelines assume that developers control all the text. Increasingly, that simply is not true.
The fact that companies like Amazon have begun experimenting with translated user reviews in 2026 says a lot about how slowly the i18n ecosystem has evolved.
Even determining which language a user wants is surprisingly complicated.
Browsers send language preferences through the Accept-Language header:
Accept-Language: en-GB,en;q=0.9,fr;q=0.8This tells the server:
In practice, implementing this properly involves:
en, en-GB, en-US)Many frameworks leave most of this logic up to developers.
Even basic locale detection often becomes custom application code.
Translation infrastructure is only half the problem.
Users still need a way to change languages.
Most i18n libraries provide the translation layer but leave the rest of the problem to the developer:
hreflang tags for SEOThese details sound small, but they quickly become a significant amount of application plumbing, especially if you’re not familiar with all the intricacies of i18n. Most companies and developers are not.
Given all of this complexity, some teams turn to automatic website translation tools. These platforms promise to translate your site automatically with minimal effort.
Several companies are building increasingly sophisticated versions of this idea. Unfortunately they introduce a different set of problems:
The result is often a site that technically supports multiple languages but delivers a noticeably worse experience, and is a black box for developers to work with.
We started with something beautifully simple:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>And ended up with translation keys, JSON dictionaries, fractured pipelines, separated backend and frontend localisation layers, and external translation tooling.
Modern web apps are incredibly sophisticated systems. Yet, i18n tooling expects workflows designed for a different era, like a Ferrari with a hand crank to start the engine.
What if internationalisation looked more like this?
<h1><T>Hello world!</T></h1>
<p>
<T>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</T
No translation keys.
No JSON dictionaries.
No manual pipelines.
Just text.
This idea is the foundation behind 18ways.
18ways treats translation as an optimised runtime concern. Extracting translation keys and managing translation files is a problem for machines, not humans.
Developers simply mark the text they want translated.
Behind the scenes, 18ways:
Everything remains SSR-friendly and SEO-safe.
Traditional i18n systems lose context.
A translator might see something like:
homeBut what does that mean?
In German, these meanings require completely different words:
Haus - a houseStartseite - the homepageStart - a navigation labelzum Anfang - return to the beginningTranslation systems that only see isolated strings struggle with these distinctions.
18ways analyses translations in the context of the actual UI.
Our backend agents review translations as they appear on real pages and optimise for:
Overflow detection is included too - looking at you, German compound nouns.
Everything that helps AI produce better translations also helps human translators.
18ways provides translators with the same context-aware environment our AI agents use.
Instead of editing JSON files, translators review text directly against the UI where it appears.
This dramatically improves translation accuracy and workflow efficiency.
Internationalisation does not need another layer of translation keys, string files, and pipeline glue.
Modern applications already have the structure, context, and runtime information we need to do this better.
The next generation of i18n should be built for server-rendered apps, dynamic content, AI-native workflows, and human translators working side by side.
That is the direction 18ways is taking.
18ways blog
An AI-native way to do i18n in Next.js, without breaking SEO.
Internationalisation (often shortened to i18n), localisation (l10n), and multilingual support all describe the same idea: adapting your product so people can use it in their own language.
They also all share the same age-old problem. Every business eventually realises they need to support languages other than their native one. At that point, the engineering team sucks through their teeth like a mechanic, “How many pages do we need to translate? That’ll set you back at least 4 sprints.”
The underlying way we implement i18n hasn’t changed in 20 years. Most i18n “best practices” were formed long before modern web architectures, and everything since has simply been layered on top of them.
I18n is the only part of modern web development that still involves exporting files and sending them to someone. It’s considered a modern set up if instead of emailing them, you upload them through an API.
In a world of CI pipelines and deploys measured in minutes instead of days, we should probably count ourselves lucky we don’t have to fax anything.
Modern web development has moved incredibly quickly.
We have:
Yet internationalisation workflows still feel like they belong to a different era.
Even relatively small applications quickly end up juggling:
Developers don’t set out to build systems like this. They come stumbling into it, as common i18n hurdles trip up developers unfamiliar with how different languages structure sentences completely differently… and reluctantly accept the status quo set 20 years ago.
Over time, internationalisation becomes one of the most complex parts of the stack.
Consider a simple UI:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>This is easy to understand. It is simple.
At some point we decide to internationalise it. So, we extract the text into a translation file:
{
"mainPage": {
"greeting": "Hello world",
"cta": "<0>Click here</0> to view your <1>{{description}}</1>"
}
}And we reference that in our code:
<h1>{t('mainPage.greeting')}</h1>
<p>
<Trans key="mainPage.cta">
<a href="#/">Click here</a> to view your <b>{{ description: serverResponse
But, wait, we now have English text both in our code, and in our translation file? Yes. Different i18n libraries put different paint on it, but trying to translate text that is partially formatted by pulling it out into a human-readable JSON file is a losing battle.
Modern UI is structured, but translation systems are built upon the foundation of flat strings.
Once markup, variables, and dynamic content enter the picture, the abstraction starts to leak.
Things get even harder when content is not static.
Take this example again:
<b>{serverResponse.productDescription}</b>That string is coming from an API. How do we turn that into a translation key?
Spoiler: you don’t. Now your backend needs to support internationalisation too.
Your backend must now manage:
Translators suddenly need access to backend systems as well.
And the problem only grows when user-generated content enters the picture.
Reviews. Comments. Marketplace listings. Forums.
Traditional i18n pipelines assume that developers control all the text. Increasingly, that simply is not true.
The fact that companies like Amazon have begun experimenting with translated user reviews in 2026 says a lot about how slowly the i18n ecosystem has evolved.
Even determining which language a user wants is surprisingly complicated.
Browsers send language preferences through the Accept-Language header:
Accept-Language: en-GB,en;q=0.9,fr;q=0.8This tells the server:
In practice, implementing this properly involves:
en, en-GB, en-US)Many frameworks leave most of this logic up to developers.
Even basic locale detection often becomes custom application code.
Translation infrastructure is only half the problem.
Users still need a way to change languages.
Most i18n libraries provide the translation layer but leave the rest of the problem to the developer:
hreflang tags for SEOThese details sound small, but they quickly become a significant amount of application plumbing, especially if you’re not familiar with all the intricacies of i18n. Most companies and developers are not.
Given all of this complexity, some teams turn to automatic website translation tools. These platforms promise to translate your site automatically with minimal effort.
Several companies are building increasingly sophisticated versions of this idea. Unfortunately they introduce a different set of problems:
The result is often a site that technically supports multiple languages but delivers a noticeably worse experience, and is a black box for developers to work with.
We started with something beautifully simple:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>And ended up with translation keys, JSON dictionaries, fractured pipelines, separated backend and frontend localisation layers, and external translation tooling.
Modern web apps are incredibly sophisticated systems. Yet, i18n tooling expects workflows designed for a different era, like a Ferrari with a hand crank to start the engine.
What if internationalisation looked more like this?
<h1><T>Hello world!</T></h1>
<p>
<T>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</T
No translation keys.
No JSON dictionaries.
No manual pipelines.
Just text.
This idea is the foundation behind 18ways.
18ways treats translation as an optimised runtime concern. Extracting translation keys and managing translation files is a problem for machines, not humans.
Developers simply mark the text they want translated.
Behind the scenes, 18ways:
Everything remains SSR-friendly and SEO-safe.
Traditional i18n systems lose context.
A translator might see something like:
homeBut what does that mean?
In German, these meanings require completely different words:
Haus - a houseStartseite - the homepageStart - a navigation labelzum Anfang - return to the beginningTranslation systems that only see isolated strings struggle with these distinctions.
18ways analyses translations in the context of the actual UI.
Our backend agents review translations as they appear on real pages and optimise for:
Overflow detection is included too - looking at you, German compound nouns.
Everything that helps AI produce better translations also helps human translators.
18ways provides translators with the same context-aware environment our AI agents use.
Instead of editing JSON files, translators review text directly against the UI where it appears.
This dramatically improves translation accuracy and workflow efficiency.
Internationalisation does not need another layer of translation keys, string files, and pipeline glue.
Modern applications already have the structure, context, and runtime information we need to do this better.
The next generation of i18n should be built for server-rendered apps, dynamic content, AI-native workflows, and human translators working side by side.
That is the direction 18ways is taking.
18ways blog
An AI-native way to do i18n in Next.js, without breaking SEO.
Internationalisation (often shortened to i18n), localisation (l10n), and multilingual support all describe the same idea: adapting your product so people can use it in their own language.
They also all share the same age-old problem. Every business eventually realises they need to support languages other than their native one. At that point, the engineering team sucks through their teeth like a mechanic, “How many pages do we need to translate? That’ll set you back at least 4 sprints.”
The underlying way we implement i18n hasn’t changed in 20 years. Most i18n “best practices” were formed long before modern web architectures, and everything since has simply been layered on top of them.
I18n is the only part of modern web development that still involves exporting files and sending them to someone. It’s considered a modern set up if instead of emailing them, you upload them through an API.
In a world of CI pipelines and deploys measured in minutes instead of days, we should probably count ourselves lucky we don’t have to fax anything.
Modern web development has moved incredibly quickly.
We have:
Yet internationalisation workflows still feel like they belong to a different era.
Even relatively small applications quickly end up juggling:
Developers don’t set out to build systems like this. They come stumbling into it, as common i18n hurdles trip up developers unfamiliar with how different languages structure sentences completely differently… and reluctantly accept the status quo set 20 years ago.
Over time, internationalisation becomes one of the most complex parts of the stack.
Consider a simple UI:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>This is easy to understand. It is simple.
At some point we decide to internationalise it. So, we extract the text into a translation file:
{
"mainPage": {
"greeting": "Hello world",
"cta": "<0>Click here</0> to view your <1>{{description}}</1>"
}
}And we reference that in our code:
<h1>{t('mainPage.greeting')}</h1>
<p>
<Trans key="mainPage.cta">
<a href="#/">Click here</a> to view your <b>{{ description: serverResponse
But, wait, we now have English text both in our code, and in our translation file? Yes. Different i18n libraries put different paint on it, but trying to translate text that is partially formatted by pulling it out into a human-readable JSON file is a losing battle.
Modern UI is structured, but translation systems are built upon the foundation of flat strings.
Once markup, variables, and dynamic content enter the picture, the abstraction starts to leak.
Things get even harder when content is not static.
Take this example again:
<b>{serverResponse.productDescription}</b>That string is coming from an API. How do we turn that into a translation key?
Spoiler: you don’t. Now your backend needs to support internationalisation too.
Your backend must now manage:
Translators suddenly need access to backend systems as well.
And the problem only grows when user-generated content enters the picture.
Reviews. Comments. Marketplace listings. Forums.
Traditional i18n pipelines assume that developers control all the text. Increasingly, that simply is not true.
The fact that companies like Amazon have begun experimenting with translated user reviews in 2026 says a lot about how slowly the i18n ecosystem has evolved.
Even determining which language a user wants is surprisingly complicated.
Browsers send language preferences through the Accept-Language header:
Accept-Language: en-GB,en;q=0.9,fr;q=0.8This tells the server:
In practice, implementing this properly involves:
en, en-GB, en-US)Many frameworks leave most of this logic up to developers.
Even basic locale detection often becomes custom application code.
Translation infrastructure is only half the problem.
Users still need a way to change languages.
Most i18n libraries provide the translation layer but leave the rest of the problem to the developer:
hreflang tags for SEOThese details sound small, but they quickly become a significant amount of application plumbing, especially if you’re not familiar with all the intricacies of i18n. Most companies and developers are not.
Given all of this complexity, some teams turn to automatic website translation tools. These platforms promise to translate your site automatically with minimal effort.
Several companies are building increasingly sophisticated versions of this idea. Unfortunately they introduce a different set of problems:
The result is often a site that technically supports multiple languages but delivers a noticeably worse experience, and is a black box for developers to work with.
We started with something beautifully simple:
<h1>Hello world!</h1>
<p>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>And ended up with translation keys, JSON dictionaries, fractured pipelines, separated backend and frontend localisation layers, and external translation tooling.
Modern web apps are incredibly sophisticated systems. Yet, i18n tooling expects workflows designed for a different era, like a Ferrari with a hand crank to start the engine.
What if internationalisation looked more like this?
<h1><T>Hello world!</T></h1>
<p>
<T>
<a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</T
No translation keys.
No JSON dictionaries.
No manual pipelines.
Just text.
This idea is the foundation behind 18ways.
18ways treats translation as an optimised runtime concern. Extracting translation keys and managing translation files is a problem for machines, not humans.
Developers simply mark the text they want translated.
Behind the scenes, 18ways:
Everything remains SSR-friendly and SEO-safe.
Traditional i18n systems lose context.
A translator might see something like:
homeBut what does that mean?
In German, these meanings require completely different words:
Haus - a houseStartseite - the homepageStart - a navigation labelzum Anfang - return to the beginningTranslation systems that only see isolated strings struggle with these distinctions.
18ways analyses translations in the context of the actual UI.
Our backend agents review translations as they appear on real pages and optimise for:
Overflow detection is included too - looking at you, German compound nouns.
Everything that helps AI produce better translations also helps human translators.
18ways provides translators with the same context-aware environment our AI agents use.
Instead of editing JSON files, translators review text directly against the UI where it appears.
This dramatically improves translation accuracy and workflow efficiency.
Internationalisation does not need another layer of translation keys, string files, and pipeline glue.
Modern applications already have the structure, context, and runtime information we need to do this better.
The next generation of i18n should be built for server-rendered apps, dynamic content, AI-native workflows, and human translators working side by side.
That is the direction 18ways is taking.