i18n
Skill1 starsChanged 6 days agoMITView on GitHub
Internationalize a project: language tags and negotiation, dates/times/time zones, numbers and currency, RTL layout, pluralization and ICU messages, collation, Unicode, and localization testing. Use when adding a language or locale, or when text, dates, numbers, or RTL layout must render correctly. Only invoke via the orcinus router.
47 other projects use a version of this, 2 of them edited.
Adopted by
Most recently taken up by
- oivanfelipe/claude-skillstheir own version, first seen Nov 8, 2026
- lobehub/lobehubtheir own version, first seen Nov 5, 2026
- Cure-Consulting-Group/ProductEngineeringSkillstheir own version, first seen Nov 4, 2026
- sorawit-w/agent-skillstheir own version, first seen Nov 1, 2026
- darknecrocities/SkillBuildertheir own version, first seen Nov 1, 2026
- TheBeardedBearSAS/claude-crafttheir own version, first seen Oct 29, 2026
Used with
Projects with it also use oss-pr, pr-automation and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CES-LtdSkilloss-pr
Use when creating a pull request, after committing changes, or when user invokes /oss-pr. Covers branch management, quality checks, commit, push, and PR creation.
Also in 3 projects that use this
CES-LtdSkillpr-automation
PR Automation Orchestrator: poll open PRs, check CI, run review, fix, and merge eligible PRs. Use when: (1) Invoked by daemon via scripts/pr-automation.sh, (2) User says "/pr-automation".
Also in 3 projects that use this
volovelySkillpr-fix
This skill should be used when the user asks to "fix PR comments", "address PR feedback", "resolve PR comments", provides a GitHub PR URL with intent to fix, or says "pr-fix". It reads all review comments on a PR, decides which need code fixes vs. replies, makes the fixes, and posts replies — all with explicit user approval before any GitHub action.
Also in 3 projects that use this
GitHubSkillstate-management
CoreAI Sandbox's TanStack Query + mock-JSON data layer. USE WHEN: editing data-fetching hooks (`app/hooks/use*.ts`), adding mock data in `app/data/`, or wiring a component to query state.
Also in 4 projects that use this
xfstudioSkillgraphql
GraphQL gives clients exactly the data they need - no more, no less. One endpoint, typed schema, introspection. But the flexibility that makes it powerful also makes it dangerous. Without proper controls, clients can craft queries that bring down your server. This skill covers schema design, resolvers, DataLoader for N+1 prevention, federation for microservices, and client integration with Apollo/urql. Key insight: GraphQL is a contract. The schema is the API documentation. Design it carefully.
Also in 3 projects that use this
MicrosoftSkillbump-version
Bump the VoxelPic version to a user-specified value. USE FOR: setting or updating the project version across all files that embed it. Applies to requests like 'bump version to X.Y.Z', 'set version', or 'update version'.
Also in 4 projects that use this
- +2 more from CES-Ltd
Other versions47 projects use a version of this.
Word for word · 0
None found.
Edited · 2
- Marvellbrazil/my-agentic-skills★ 496% same
- dafaalz/agent-skills★ 213% same
Wrote their own version · 45
- lobehub/lobe-chat★ 84ksame name
- lobehub/lobehub★ 84ksame name
- iOfficeAI/AionUi★ 34ksame name
- massCodeIO/massCode★ 7.1ksame name
- leookun/cursor-byok★ 3.2ksame name
- Pixeval/Pixeval★ 3.2ksame name
- akiver/cs-demo-manager★ 2ksame name
- d-kimuson/claude-code-viewer★ 1.3ksame name
- huoshen80/ReinaManager★ 737same name
- OpenClaudia/openclaudia-skills★ 731same name
35 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository35 other files it gives its agents.
- accessibilitySkill
- api-and-interface-designSkill
- architectureSkill
- ask-questions-if-underspecifiedSkill
- breaking-changeSkill
- buildSkill
- codebase-knowledge-builderSkill
- database-designerSkill
- diagnosing-bugsSkill
- finalizeSkill
- frontend-architectureSkill
- frontend-data-contractsSkill
- frontend-optimistic-mutationsSkill
- handoffSkill
- idea-calibrateSkill
- idea-captureSkill
- incomplete-refactorSkill
- independent-reviewSkill
- issue-triageSkill
- mcp-builderSkill
- monitoring-observabilitySkill
- monitoringSkill
- mutation-testing-pythonSkill
- mutation-testingSkill
- orcinusSkill
- orcinus-verifySkill
- performance-optimizationSkill
- refactorSkill
- registry-publishSkill
- scaffoldSkill
- security-reviewSkill
- skill-creatorSkill
- visual-regressionSkill
- wazaSkill
- webapp-testingSkill
The file
We split this skill into the rules it gives an agent
7 rules. 0 are common, 4 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 38 edited versions we read keep these.
4
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 29
When the language set is ambiguous and the user did not name one, ask before implementing.
- Very specific: line 81
If the user narrowed the domains, load only those plus intl-language.md and intl-testing-and-qa.md.
- Distinctive: line 87
Search for the defects that indicate a locale-hardcoded codebase.
- Distinctive: line 126
Testing: Add the pseudolocale, the lint rules, and the locale matrix so the work cannot regress.
- Very specific: line 128
Follow the conventions already in the repository.
- Very specific: line 130
Do not introduce a new dependency when the platform formatter covers the need.
- Distinctive: line 134
Never claim the work is done without running these.
“Common” is measured: kept by at least 6 in 10 of the 38 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Internationalization (i18n)
Make a codebase correct outside a single locale. This skill audits and then implements internationalization across nine domains, each documented in a reference module under references/.
The Scope Contract
The user may narrow the work by naming aspects, languages, or both. Parse the request before doing anything else.
| Request | Languages in scope | Domains in scope |
/i18n (bare) | Detect from the project; ask if ambiguous | All nine |
/i18n I want language just to be english and spanish | en, es only | All nine |
/i18n only fix the date and time handling | Current set | intl-date-and-time-format.md only |
/i18n add Arabic support | Existing plus ar | All nine, with RTL and BiDi promoted |
/i18n audit only, change nothing | Detect | All nine, report without editing |
Two rules govern a narrowed request:
- A narrowed language set narrows the configuration, not the correctness of the code. If only
enandesare requested, do not add RTL stylesheets or Arabic plural rules — but do still use logical CSS properties, locale-aware formatting APIs, and ICU messages, because those cost nothing now and make the next language a configuration change rather than a rewrite. - A narrowed domain set does not excuse breaking a sibling domain. Adding date formatting while leaving hardcoded concatenated strings still produces broken output. Note the out-of-scope defects you observe, report them, and do not fix them unless the user widens the scope.
When the language set is ambiguous and the user did not name one, ask before implementing. Do not guess a target market.
Phase 1 — Reconnaissance
Establish what exists before proposing anything. Never recommend a library the project already uses, and never migrate an existing i18n library without the user asking.
Detect the stack and the existing i18n surface:
ls -a
cat package.json 2>/dev/null | head -60
cat pyproject.toml composer.json Gemfile go.mod 2>/dev/null | head -60Find an existing i18n implementation before writing one:
grep -rIl --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "i18next|react-intl|vue-i18n|next-intl|formatjs|intl-messageformat|gettext|babel|lingui|icu|MessageFormat" . | head -30
find . -path ./node_modules -prune -o \
\( -name "*.po" -o -name "*.xliff" -o -name "*.arb" -o -name "*.ftl" -o -name "messages*.json" -o -name "locales" -o -name "i18n" \) -print 2>/dev/null | head -30Record these findings — they drive every later decision:
| Question | Why it matters |
| What is the runtime? (Node, browser, Python, PHP, JVM, Go, Rust, mobile) | Determines whether Intl is available or a library is required |
| Which i18n library is already present? | Extend it; do not replace it |
| Where do translations live? Which format? | Determines the catalog structure |
| Is there a TMS or a translation vendor in the loop? | Constrains the file format and key policy |
| Is a locale stored per user? Where? | Determines the negotiation source |
| Does the project already store timestamps with a zone? | Determines how much date work is a migration |
Are there existing locale-specific branches (if (locale === 'en'))? | These are the highest-signal defects |
Phase 2 — Load Only the Relevant Modules
Load a reference module when its domain is in scope. Read the file in full; each is written to be self-contained.
| Domain | Module | Load when |
| Language tags, locale negotiation, language selection | references/intl-language.md | Always. This is the entry point for every other domain. |
| Dates, times, time zones, calendars | references/intl-date-and-time-format.md | The project renders, parses, or stores any date or time |
| Numbers, currency, units, measurement | references/intl-number-and-currency.md | The project displays money, counts, percentages, or quantities |
| Bidirectional text and RTL layout | references/intl-bidi.md | Any RTL language is in scope, or the UI uses physical CSS directions |
| Pluralization, gender, ICU messages | references/intl-pluralization.md | Any user-facing string interpolates a count or a variable |
| Collation, sorting, string comparison | references/intl-collation-and-sorting.md | The project sorts, searches, deduplicates, or compares user text |
| Unicode text processing and segmentation | references/intl-text-processing.md | The project truncates, counts, normalizes, or manipulates strings |
| Content, assets, cultural adaptation | references/intl-content-and-assets.md | Always, for the catalog structure and layout resilience |
| Localization testing and QA | references/intl-testing-and-qa.md | Always. Establishes the gate that prevents regression. |
If the user narrowed the domains, load only those plus intl-language.md and intl-testing-and-qa.md. The language module defines the tag vocabulary every other module depends on, and the testing module defines how you prove the work.
Phase 3 — Audit
Produce a findings list before editing. Each finding names a file, a line, the defect, and the concrete fix.
Search for the defects that indicate a locale-hardcoded codebase. These greps are starting points, not a complete audit:
grep -rn --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "toLocaleDateString\(\)|toLocaleString\(\)|new Date\(.*\)\.getDate\(\)" . | head -40
grep -rn --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "\.toUpperCase\(\)|\.toLowerCase\(\)" . | head -40
grep -rn --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "=== *1|=== *0|count *[<>=]+ *1|\$\{count\}" . | head -40
grep -rn --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "margin-left|margin-right|padding-left|padding-right|text-align: *(left|right)|left:|right:" . | head -40
grep -rn --exclude-dir={node_modules,.git,dist,build,vendor} \
-E "\.sort\(\)|ORDER BY" . | head -40Classify each finding by severity, because the user needs to know what to fix first:
| Severity | Meaning | Examples |
| Critical | Produces wrong data, not just wrong presentation | Storing a local wall-clock time as an instant; parsing a localized number with parseFloat; truncating a string by code unit and corrupting it |
| High | Visibly broken for a real locale | if (count === 1) pluralization; toUpperCase() on Turkish text; sort() on non-ASCII; date rendered in the server's zone |
| Medium | Correct today, blocks the next language | Physical CSS properties; concatenated sentence fragments; a hardcoded MM/DD/YYYY format |
| Low | Polish and completeness | Missing lang on inline foreign text; no pseudolocale in CI |
Phase 4 — Implement
Apply fixes in this order. The order matters because later work depends on earlier decisions.
- Locale model. Define how a locale is represented, negotiated, resolved, and persisted. Everything else consumes this.
- Catalog structure. Establish the message file layout, key policy, and placeholder syntax before migrating a single string.
- String extraction. Replace hardcoded user-facing strings with catalog lookups, including the ones that look safe.
- Formatting. Replace hand-rolled date, number, and currency formatting with the platform formatter or the library's.
- Pluralization and grammar. Convert every count-dependent string to an ICU plural. Never leave a numeric conditional.
- Direction and layout. Introduce
dir, logical CSS properties, and bidi isolation where needed. - Sorting and comparison. Replace code-unit comparison with a locale-aware collator.
- Testing. Add the pseudolocale, the lint rules, and the locale matrix so the work cannot regress.
Follow the conventions already in the repository. If the project has an AGENTS.md, CLAUDE.md, CONTRIBUTING.md, or a documented i18n policy, that policy wins over any recommendation in these modules. Report the conflict rather than silently overriding it.
Do not introduce a new dependency when the platform formatter covers the need. Intl in JavaScript, ICU in Java and PHP, Babel in Python, and golang.org/x/text in Go all cover far more than most teams assume.
Phase 5 — Verify
Never claim the work is done without running these.
- The app builds and the existing test suite passes.
- Every locale in scope renders the audited screens without a fallback to the default language.
- No raw formatting API remains on a user-facing path (
toLocaleDateString()with no locale or options,new Date().toString(),strftimewith a hardcoded pattern). - No count-dependent string uses a numeric comparison.
- No
toUpperCase()/toLowerCase()remains on a value used for comparison or identity. - Sorting of user-visible lists uses a locale-aware collator.
- Timestamps are stored with an explicit zone or as an instant, and rendered in the viewer's zone.
- Layout uses logical properties; an RTL locale was rendered if one is in scope.
- Truncation and character counting respect grapheme clusters.
- The pseudolocale build runs and surfaces no hardcoded strings.
- The locale matrix is wired into CI.
Report what you could not verify and why. An unverified claim is worse than a stated gap.
Output
Report back in this shape, trimmed to what is relevant:
## Scope
Languages: en, es — Domains: all nine
## What Exists
Runtime: Node 22 / React 19. Library: react-intl 7. Catalogs: JSON per locale.
Timestamps: stored as UTC epoch ms. Locale source: user profile.
## Findings
| Severity | Location | Defect | Fix |
| -------- | ---------------------- | ---------------------------------------------- | ------------------------------------------------------- |
| Critical | src/orders/total.ts:42 | `parseFloat(row.amount)` on a localized string | Parse with the API formatter, keep a raw numeric column |
| High | src/cart/Cart.tsx:88 | `items.length === 1 ? 'item' : 'items'` | ICU plural via `<FormattedMessage>` |
## Changes Applied
<grouped by domain, naming the files touched>
## Verification
<the checklist above, with the actual result of each>
## Out of Scope / Not Verified
<defects observed but not fixed, and why>For a change touching many files, publish the report as an Artifact so the team can review it; keep a short summary in the reply.
Common Mistakes
| Mistake | Why It Breaks | Correct Approach |
| Adding a library before checking for one | Two i18n systems fight over the same strings | Detect first; extend what exists |
if (count === 1) | Plural rules are per-language; Polish has four categories, Arabic six, Japanese one | Use ICU plural with the CLDR categories |
parseFloat(localizedString) | German 1.234,56 parses as 1.234 — a silent 1000x error | Parse with the locale-aware formatter; store a raw numeric value |
toLocaleDateString() with no locale | Uses the server or CI locale, not the viewer's | Pass the resolved locale explicitly |
| Storing a local wall-clock time as an instant | DST transitions corrupt it and it renders wrong in other zones | Store an instant plus an IANA zone, or a zone-free local time when that is the true meaning |
margin-left for direction-aware spacing | The layout does not mirror in RTL | Use margin-inline-start and friends |
str.toUpperCase() for comparison | Turkish dotless ı and German ß break equality and search | Use Intl.Collator with sensitivity: 'accent', or toLocaleUpperCase(locale) |
arr.sort() on user text | Sorts by code unit; Å, é, and Z land in the wrong places | Intl.Collator(locale).compare |
| Concatenating sentence fragments | Word order and grammar differ per language; the result is untranslatable | One complete message per unit with named placeholders |
Truncating with .substring() | Splits grapheme clusters and corrupts emoji, flags, and Indic scripts | Intl.Segmenter with granularity: 'grapheme' |
| Adding RTL styling only when RTL is requested, but keeping physical CSS | The next language costs a rewrite | Use logical properties from the start; it is free |
| Machine-translating legal or regulatory copy | Legally invalid and often wrong | Flag it for human translation |
| Assuming English text length | German and Finnish run 30-40% longer and break fixed layouts | Design for expansion; test with the pseudolocale |
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

