i18n-localization

Summary

Internationalization and localization patterns for multi-language app support.

  • Covers core i18n concepts, implementation patterns for React, Next.js, and Python, and file structure organization for managing translations across locales
  • Includes best practices for using translation keys, namespacing, pluralization, date/number formatting, and ICU message format to avoid common pitfalls
  • Provides RTL (right-to-left) layout guidance using CSS logical properties for languages like Arabic and Hebrew
  • Includes a hardcoded string detection script to identify missing translations and ensure all user-facing text uses translation keys
SKILL.md

i18n & Localization

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


1. Core Concepts

Term Meaning
i18n Internationalization - making app translatable
L10n Localization - actual translations
Locale Language + Region (en-US, tr-TR)
RTL Right-to-left languages (Arabic, Hebrew)

2. When to Use i18n

Project Type i18n Needed?
Public web app ✅ Yes
SaaS product ✅ Yes
Internal tool ⚠️ Maybe
Single-region app ⚠️ Consider future
Personal project ❌ Optional

3. Implementation Patterns

React (react-i18next)

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

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

Issue Solution
Missing translation Fallback to default language
Hardcoded strings Use linter/checker script
Date format Use Intl.DateTimeFormat
Number format Use Intl.NumberFormat
Pluralization Use ICU message format

7. RTL Support

/* 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

Before shipping:

  • 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

Script Purpose Command
scripts/i18n_checker.py Detect hardcoded strings & missing translations python scripts/i18n_checker.py <project_path>

When to Use

This skill is applicable to execute the workflow or actions described in the overview.

Weekly Installs
1.3K
GitHub Stars
27.9K
First Seen
Jan 20, 2026
Installed on
opencode1.1K
gemini-cli1.1K
codex1.0K
github-copilot995
cursor940
amp846