When & Why to Use This Skill
This Claude skill streamlines the internationalization (i18n) and localization (L10n) process for modern software development. It provides automated patterns for detecting hardcoded strings, managing complex locale file structures, and implementing Right-to-Left (RTL) support. By integrating best practices for frameworks like React, Next.js, and Python, it ensures your application is globally accessible, culturally adapted, and technically robust against common localization pitfalls.
Use Cases
- Codebase Auditing: Automatically scan and identify hardcoded strings within components to migrate them into structured translation keys.
- Global Market Expansion: Implement RTL (Right-to-Left) layout support for languages like Arabic and Hebrew using CSS logical properties and specialized UI patterns.
- Multi-Framework Localization: Apply standardized i18n implementation patterns across different tech stacks, including react-i18next, next-intl, and Python gettext.
- Automated Quality Checks: Utilize the i18n_checker script to detect missing translation keys and ensure locale file consistency before deployment.
| name | i18n-localization |
|---|
| description | Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support. |
|---|
| allowed-tools | Read, Glob, Grep |
|---|
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:
Script
| Script |
Purpose |
Command |
scripts/i18n_checker.py |
Detect hardcoded strings & missing translations |
python scripts/i18n_checker.py <project_path> |
