i18n & Localization

Internationalization (i18n) and Localization (L10n) best practices.

---

1. Core Concepts

---

2. When to Use i18n

---

3. Implementation Patterns

React (react-i18next)

Copy
import { useTranslation } from 'react-i18next';

function Welcome() {
  const { t } = useTranslation();
  return <h1>{t('welcome.title')}</h1>;
}
`### Next.js (next-intl)`
import { useTranslations } from 'next-intl';

export default function Page() {
  const t = useTranslations('Home');
  return <h1>{t('title')}</h1>;
}
`### Python (gettext)`
from gettext import gettext as _

print(_("Welcome to our app"))

---

4. File Structure

Copy
locales/
├── en/
│   ├── common.json
│   ├── auth.json
│   └── errors.json
├── tr/
│   ├── common.json
│   ├── auth.json
│   └── errors.json
└── ar/          # RTL
    └── ...

---

5. Best Practices

DO ✅

• Use translation keys, not raw text
• Namespace translations by feature
• Support pluralization
• Handle date/number formats per locale
• Plan for RTL from the start
• Use ICU message format for complex strings

DON'T ❌

• Hardcode strings in components
• Concatenate translated strings
• Assume text length (German is 30% longer)
• Forget about RTL layout
• Mix languages in same file

---

6. Common Issues

---

7. RTL Support

Copy
/* CSS Logical Properties */
.container {
  margin-inline-start: 1rem;  /* Not margin-left */
  padding-inline-end: 1rem;   /* Not padding-right */
}

[dir="rtl"] .icon {
  transform: scaleX(-1);
}

---

8. Checklist

• All user-facing strings use translation keys
• Locale files exist for all supported languages
• Date/number formatting uses Intl API
• RTL layout tested (if applicable)
• Fallback language configured
• No hardcoded strings in components

---

Script