The i18n Gap: How AI Assistants Build English-Only Apps
You built an app with Cursor, deployed it, and a user from Japan reported that the app is unusable because all the text is in English. You check the code and realize that every string is hardcoded in English, there is no internationalization (i18n) library, and there is no way to switch languages. This is the i18n gap, and it is one of the most common failures in AI-generated apps. AI assistants build apps with hardcoded English strings, because that is the default in their training data, which makes the apps unusable for the majority of the world's population who do not speak English. Here are the 6 reasons AI assistants build English-only apps, and the production checklist to fix them.
The direct answer is that internationalization (i18n) is the practice of building apps that support multiple languages, and it is essential for apps with a global audience. AI assistants generate code with hardcoded English strings, because i18n is not the default in most frameworks and the LLM's training data is dominated by English examples. The 6 reasons are: hardcoded strings, no i18n library, no locale detection, no RTL support, no pluralization, and no date/number formatting. Each one has a known cause and a known fix, and applying all 6 fixes gives you a production-ready i18n system. For more on production readiness, see our article on why AI apps break on the first real user.
Reason 1: Hardcoded Strings
The most common reason AI assistants build English-only apps is hardcoded strings. AI assistants write instead of , which means the text cannot be translated without modifying the code. The fix is to extract all user-facing strings into a translation file (e.g., en.json, ja.json) and to reference them via a translation function (e.g., t('click_me')). For Next.js, use next-intl or next-i18next. For Vite, use react-i18next. For more on string management, see our article on the state management mess.
Reason 2: No i18n Library
The second reason is no i18n library. i18n requires a library that handles translation loading, locale switching, and string interpolation. AI assistants rarely set up an i18n library, because it is not part of the default boilerplate. The fix is to install and configure an i18n library at the beginning of the project. For Next.js, use next-intl (the recommended i18n library for the App Router). For Vite, use react-i18next. For more on library setup, see our article on the dependency hell trap.
Reason 3: No Locale Detection
The third reason is no locale detection. When a user visits your app, the app should detect their preferred language (from the Accept-Language header or the URL) and display the app in that language. AI assistants rarely implement locale detection, which means the app always displays in English, regardless of the user's preference. The fix is to implement locale detection: read the Accept-Language header (on the server) or the navigator.language property (on the client), match it against your supported languages, and redirect to the appropriate locale. For more on headers, see our article on the security headers gap.
Reason 4: No RTL Support
The fourth reason is no RTL (right-to-left) support. Languages like Arabic, Hebrew, and Persian are written right-to-left, which means the layout needs to be mirrored. AI assistants rarely implement RTL support, which means the app is unusable for RTL language speakers. The fix is to use CSS logical properties (e.g., margin-inline-start instead of margin-left) and to set the dir attribute on the HTML element based on the locale. For Tailwind CSS, use the rtl: variant for RTL-specific styles. For more on CSS, see our article on the accessibility gap.
Reason 5: No Pluralization
The fifth reason is no pluralization. English has simple pluralization (1 item, 2 items), but other languages have complex pluralization rules (e.g., Arabic has 6 plural forms, Russian has 3). AI assistants rarely implement pluralization, which means the app shows "1 items" or "2 item" in non-English languages. The fix is to use the i18n library's pluralization feature, which handles the plural rules for each language. For react-i18next, use the count option: t('items', { count: 2 }).
Reason 6: No Date/Number Formatting
The sixth reason is no date/number formatting. Dates and numbers are formatted differently in different locales (e.g., 1,000.00 in the US vs 1.000,00 in Germany). AI assistants rarely implement locale-aware formatting, which means the app shows US-style dates and numbers regardless of the locale. The fix is to use the Intl API (built into JavaScript) for locale-aware formatting: new Intl.NumberFormat(locale).format(1000) and new Intl.DateTimeFormat(locale).format(date).
Step-by-Step: Adding i18n to a Next.js App
Here is how to add i18n to a Next.js app using next-intl.
Step 1: Install next-intl
npm install next-intlStep 2: Create translation files
// messages/en.json
{
"click_me": "Click me",
"items": "{count, plural, one {# item} other {# items}}",
"welcome": "Welcome, {name}!"
}
// messages/ja.json
{
"click_me": "クリックしてください",
"items": "{count}個のアイテム",
"welcome": "ようこそ、{name}さん！"
}Step 3: Configure next-intl
// i18n.ts
import { getRequestConfig } from 'next-intl/server';
import { notFound } from 'next/navigation';
const locales = ['en', 'ja'];
export default getRequestConfig(async ({ locale }) => {
if (!locales.includes(locale)) notFound();
return {
messages: (await import(`./messages/${locale}.json`)).default,
};
});Step 4: Use translations in components
import { useTranslations } from 'next-intl';
function MyComponent() {
const t = useTranslations();
return (
{t('items', { count: 2 })}
{t('welcome', { name: 'Alice' })}
);
}Step 5: Implement locale detection
// middleware.ts
import { createMiddleware } from 'next-intl/middleware';
export default createMiddleware({
locales: ['en', 'ja'],
defaultLocale: 'en',
localeDetection: true,
});
export const config = {
matcher: ['/((?!api|_next|.*\\..*).*)'],
};Step 6: Verify with deployxa doctor
Run deployxa doctor to verify your app's health. The 14-point readiness engine checks SSL, DNS, environment variables, health endpoints, and container status.
Common Pitfalls and Troubleshooting
The first pitfall is not extracting all strings. If you miss some strings, they will remain in English, which creates a poor user experience for non-English speakers. The fix is to use a tool like i18next-parser to automatically extract strings from your code. The second pitfall is not testing with different locales. If you only test in English, you might miss layout issues (e.g., German text is longer than English text, which can break layouts) and RTL issues. The fix is to test with multiple locales, including an RTL locale (e.g., Arabic). The third pitfall is not handling missing translations. If a translation is missing, the app should fall back to English (or show the translation key), not crash. The fix is to configure the i18n library to fall back to a default locale. The fourth pitfall is not updating translations when adding features. When you add a new feature, you need to add new translations for all supported languages. The fix is to use a translation management tool (e.g., Crowdin, Lokalise) that tracks missing translations. The fifth pitfall is not considering cultural differences. Translation is not just about language; it is also about culture. For example, colors, icons, and date formats have different meanings in different cultures. The fix is to work with native speakers to ensure your app is culturally appropriate.
Conclusion: i18n Is for Everyone
The i18n gap is not a sign that your AI assistant did a bad job. It is a sign that i18n is not the default, and AI assistants do not add it. By applying the 6 fixes above (extract strings, install i18n library, detect locale, support RTL, handle pluralization, format dates/numbers), you can build an app that is usable by everyone, regardless of their language. Stop shipping English-only apps and start building for the world.
Ready to ship a multilingual app? Drag your project to Deployxa Drop for an instant live preview, or install the CLI with npm i -g @deployxa/cli and deploy from your terminal. For more on AI coding patterns, see our articles on the security headers gap and the accessibility gap. Learn about the logging gap and the monitoring gap in our companion articles. Explore our free developer tools to speed up your workflow.