home / skills / xfstudio / skills / i18n-localization

i18n-localization skill

/i18n-localization

This skill helps you implement i18n localization patterns, detect hardcoded strings, manage locale files, and ensure RTL support across projects.

This is most likely a fork of the i18n-localization skill from vudovn
npx playbooks add skill xfstudio/skills --skill i18n-localization

Review the files below or copy the command above to add this skill to your agents.

Files (2)
SKILL.md
3.0 KB
---
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)

```tsx
import { useTranslation } from 'react-i18next';

function Welcome() {
  const { t } = useTranslation();
  return <h1>{t('welcome.title')}</h1>;
}
```

### Next.js (next-intl)

```tsx
import { useTranslations } from 'next-intl';

export default function Page() {
  const t = useTranslations('Home');
  return <h1>{t('title')}</h1>;
}
```

### Python (gettext)

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

Overview

This skill provides patterns and tooling for internationalization (i18n) and localization (L10n) in projects. It helps detect hardcoded strings, manage locale files, and enforce best practices including pluralization, date/number formatting, and RTL support. The goal is predictable translation workflows and fewer runtime localization bugs.

How this skill works

The skill inspects source files to find hardcoded user-facing strings and missing translation keys. It recommends or generates locale file structure, checks pluralization and ICU usage, and flags RTL layout issues. A provided script can be run to scan a project path and list problems for remediation.

When to use it

  • Public web apps and SaaS products that must support multiple languages.
  • Projects that will expand to new regions or require professional translations.
  • Codebases where reviewers need automated detection of hardcoded text.
  • Apps that must support RTL languages like Arabic or Hebrew.
  • Early in a project to avoid technical debt from scattered strings.

Best practices

  • Use translation keys and namespaces instead of raw text in components.
  • Organize locale files by feature (e.g., common, auth, errors) per locale.
  • Use ICU message format for plurals and complex interpolations.
  • Format dates and numbers with the Intl API, not custom code.
  • Plan and test RTL layouts early; use CSS logical properties.
  • Run an i18n checker script during CI to catch hardcoded strings.

Example use cases

  • Scan a React or Next.js app for hardcoded labels and suggest keys.
  • Generate or validate locale directory structure (en/, tr/, ar/).
  • Detect missing translations and show fallback behavior before release.
  • Verify pluralization and ICU usage across locale files.
  • Flag layout and CSS rules that break under dir="rtl" and suggest logical properties.

FAQ

How do I find hardcoded strings?

Run the provided scanner against your project path; it parses source files and reports string literals that look user-facing.

What if a language needs different formatting rules?

Use Intl.DateTimeFormat and Intl.NumberFormat per locale, and keep formatting logic outside translation strings.