PluginBench
Skill
Pass
Audit score 90

i18n-localization

sickn33/antigravity-awesome-skills

Detect hardcoded strings, manage translations, and implement RTL support for multi-language apps.

What is i18n-localization?

Internationalization (i18n) and localization (L10n) patterns for making applications translatable and supporting multiple languages and regions. Use this skill when building public web apps, SaaS products, or any application targeting international audiences.

  • Detect hardcoded strings in components using automated checker scripts
  • Manage translation keys and locale files organized by feature namespace
  • Support pluralization and complex messages using ICU message format
  • Handle date and number formatting per locale using Intl API
  • Implement RTL (right-to-left) layout support for Arabic, Hebrew, and similar languages
  • Provide fallback language configuration and missing translation handling

How to install i18n-localization

npx skills add https://github.com/sickn33/antigravity-awesome-skills --skill i18n-localization
Claude Code
Cursor
Windsurf
Cline

How to use i18n-localization

  1. 1.Choose an i18n library based on your framework (react-i18next for React, next-intl for Next.js, gettext for Python)
  2. 2.Create a locales directory structure with subdirectories for each language (en, tr, ar, etc.)
  3. 3.Replace all hardcoded user-facing strings with translation keys using the library's translation function
  4. 4.Organize translation keys by feature namespace (common.json, auth.json, errors.json)
  5. 5.Run the i18n_checker.py script to detect any remaining hardcoded strings: python scripts/i18n_checker.py <project_path>
  6. 6.Configure fallback language and locale detection
  7. 7.Implement date/number formatting using Intl.DateTimeFormat and Intl.NumberFormat APIs
  8. 8.For RTL languages, use CSS logical properties (margin-inline-start, padding-inline-end) instead of directional properties

Use cases

Good for
  • Building a SaaS product that needs to support multiple languages and regions
  • Converting a single-language React or Next.js app to support international users
  • Implementing RTL layout for an app targeting Arabic or Hebrew-speaking markets
  • Setting up locale file structure and translation key namespacing for a new project
  • Auditing an existing codebase to find and replace hardcoded user-facing strings
Who it's for
  • Frontend developers building public web applications
  • SaaS product teams expanding to international markets
  • Full-stack developers implementing multi-language support
  • Teams supporting right-to-left languages

i18n-localization FAQ

What's the difference between i18n and L10n?

i18n (internationalization) is the process of making your app translatable by using translation keys instead of hardcoded strings. L10n (localization) is the actual translation of content into specific languages and regions.

When should I implement i18n?

Implement i18n for public web apps and SaaS products from the start. For internal tools, consider it if future expansion is likely. For single-region or personal projects, it's optional.

How do I detect hardcoded strings in my codebase?

Use the included i18n_checker.py script: python scripts/i18n_checker.py <project_path>. It scans your code for hardcoded strings and missing translations.

How should I structure my locale files?

Organize by language/region (en/, tr/, ar/) with feature-based namespacing inside (common.json, auth.json, errors.json). This keeps translations maintainable and prevents key collisions.

What's important for RTL language support?

Use CSS logical properties (margin-inline-start instead of margin-left) rather than directional properties. Test RTL layout thoroughly and consider mirroring icons or images where appropriate.

Full instructions (SKILL.md)

Source of truth, from sickn33/antigravity-awesome-skills.


name: i18n-localization description: "Internationalization and localization patterns. Detecting hardcoded strings, managing translations, locale files, RTL support." risk: safe source: community date_added: "2026-02-27"

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>

When to Use

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

Limitations

  • Use this skill only when the task clearly matches the scope described above.
  • Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
  • Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.