mcpField
I
i18n-localization

i18n-localization

github.com/davila7Development33.0k568 installsUpdated today
Repository

About i18n-localization

i18n-localization is a practical guide to internationalization and localization for application developers. It covers implementation patterns, locale file organization, RTL support, and release checks, and includes a script for detecting hardcoded strings and missing translations.

Key features

  1. 01Explains i18n and L10n concepts
  2. 02Shows React, Next.js, and Python examples
  3. 03Describes locale file organization
  4. 04Covers plural, date, and number formatting
  5. 05Offers RTL layout guidance
  6. 06Includes a translation checker script

Use cases

  1. 01Plan multilingual support for an application
  2. 02Add translations to React, Next.js, or Python apps
  3. 03Check for hardcoded text and missing translations
  4. 04Test RTL layouts and localized formats

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/davila7/claude-code-templates --skill i18n-localization

After installing, type/i18n-localizationin Claude Code to confirm it loaded.

Bundled filesscripts/i18n_checker.py

Details

From the project README

i18n & Localization

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


1. Core Concepts

TermMeaning
i18nInternationalization - making app translatable
L10nLocalization - actual translations
LocaleLanguage + Region (en-US, tr-TR)
RTLRight-to-left languages (Arabic, Hebrew)

2. When to Use i18n

Project Typei18n 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

IssueSolution
Missing translationFallback to default language
Hardcoded stringsUse linter/checker script
Date formatUse Intl.DateTimeFormat
Number formatUse Intl.NumberFormat
PluralizationUse 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

ScriptPurposeCommand
scripts/i18n_checker.pyDetect hardcoded strings & missing translationspython scripts/i18n_checker.py <project_path>

Comments

Markdown supported