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

inngest
Inngest expert for serverless-first background jobs, event-driven

instagram-automation
Automate Instagram tasks via Rube MCP (Composio): create posts, carousels, manage media, get insights, and publishing limits. Always search tools first for current schemas.

interactive-portfolio
Expert in building portfolios that actually land jobs and clients -

javascript-mastery
33+ essential JavaScript concepts every developer should know, inspired by [33-js-concepts](https://github.com/leonardomso/33-js-concepts).

kaizen
Guide for continuous improvement, error proofing, and standardization. Use this skill when the user wants to improve code quality, refactor, or discuss process improvements.

kubernetes-architect
Expert Kubernetes architect specializing in cloud-native infrastructure, advanced GitOps workflows (ArgoCD/Flux), and enterprise container orchestration.