principlejavascriptModerate
i18n Namespace Organization for Large Translation Files
Viewed 0 times
i18n namespacetranslation namespacessplit translationsreact-i18next namespacenext-intl namespacetranslation structure
Problem
A single
en.json file with thousands of keys becomes hard to maintain and causes unnecessary data to be sent to every page.Solution
Split translations into namespaces by feature or page. Load only the namespaces a page needs.
messages/
en/
common.json # shared: nav, buttons, errors
home.json # homepage-specific
auth.json # login/signup
dashboard.json # dashboard// next-intl server-side namespace
import { getTranslations } from 'next-intl/server';
export default async function DashboardPage() {
const t = await getTranslations('dashboard');
return <h1>{t('title')}</h1>;
}
// react-i18next hook
import { useTranslation } from 'react-i18next';
function Dashboard() {
const { t } = useTranslation('dashboard');
return <h1>{t('title')}</h1>;
}Why
Namespaces reduce bundle size by shipping only the strings a user needs for the current view. They also make ownership clear: each team owns their namespace file.
Gotchas
- Define a
commonnamespace for shared strings (buttons, error messages) to avoid duplication across namespaces. - Nested key structures (
auth.login.button) vs flat (auth_login_button) both work but must be consistent throughout the project. - Some TMS tools have trouble with deeply nested JSON — flatten to two levels max.
- In next-intl, only namespaces passed to
NextIntlClientProviderare available in client components.
Revisions (0)
No revisions yet.