Practical Localizer

The problem

a correct translation ≠ a natural one

Traditional translation asks “what does this sentence translate to?” Practical Localizer asks “what would a real user expect this application to say here?”

English:   Chair
Literal:   a dictionary-valid, formal/literary word
Practical: the borrowed word people actually use for the object

Both are “the translation”. Only one of them sounds like a modern app — and which one that is differs by language, product and audience. The same reasoning gives the opposite answer in a neighbouring language where an ordinary native word is in everyday use, which is exactly why no blanket rule survives contact with a real product.

And the damage is rarely only stylistic

"Hello, {{name}}"  →  "হ্যালো"           the placeholder is gone; nothing fails
t("remove")        →  "delete forever"  the handler was removeMember()
one concept        →  three target words, one per translation batch
{count, plural,…}  →  a single fixed form in a locale that needs six

When it activates

No slash command needed. Installed, it is loaded when a request needs it and stays out of the way otherwise — and when it does shape the work, one ⚡ line says so. How the skills work together →

Translation vs localization

How it works

source application  →  localization architecture  →  language usage profile
   →  existing terminology  →  context extraction  →  translation strategy
   →  natural localization  →  technical validation  →  consistency review

Every meaningful term gets exactly one strategy, chosen from evidence:

Three modes

Localize never touches application logic, variable or route names, CSS, or your git history. Hardcoded strings, concatenated sentences and formatter bugs are reported as findings — fixing them is a source change, and that is your call.

Example output

Abbreviated, from a review of an existing Bengali locale:

LOCALIZATION REVIEW
────────────────────────────────
Target  Bengali (bn-BD)   Reviewed  742 strings
High-confidence 18 · Medium 27 · Technical 3

#1  greeting.hello — BLOCKING TECHNICAL ISSUE
    Source "Hello, {{name}}" → current "হ্যালো"
    The interpolation was dropped; the name never renders.
    Confidence: HIGH (mechanical)

#2  team.remove — Context / terminology
    Current মুছে ফেলুন ("erase") → recommended সরিয়ে দিন
    Rendered in <TeamMemberRow>, handler removeMember(). The member is
    taken off the team, not deleted. Bengali distinguishes the two;
    English does not.
    Confidence: HIGH — the handler and surrounding UI resolve the meaning

#3  sign in — Terminology inconsistency
    লগইন (18 occurrences) · প্রবেশ করুন (2 occurrences)
    Recommend the established project term everywhere. Adding a third,
    better-sounding synonym would be the worst outcome.

Five worked language examples ship with the skill: Bengali, Hindi, Japanese, Arabic, and a European three-language pass. Each one ends by stating what it does not claim.

Technical validation

Language quality is a judgement call. These are not, and they run on everything produced or reviewed.

What it will not do

• Claim native authority. Never “native speakers say this” — instead “this is the more common software convention”, with the evidence named
• Guess hidden grammar. When the target needs gender, formality or a counter the source does not carry, it says so and offers the options
• Encode stereotypes. Language use varies by region, age, profession, audience and product. Those are factors, never rules
• Invent numbers. No fabricated string counts, no claimed validation that did not run, no cited source it did not read
• Touch your source code. Only localization resources, only in localize mode

Localization systems it recognizes

Detected by inspection, not assumption: i18next and react-i18next, react-intl / FormatJS, next-intl, next-i18next, vue-i18n, Laravel lang/, gettext .po, Rails I18n, Flutter .arb, Android strings.xml, Apple .strings and .stringsdict, Java properties — plus JSON, YAML, XML, PHP and TS/JS catalogs generally.

If your project does localization some other way, the skill reads how it works before touching it.

Install

Any Agent Skills-compatible agent

Claude Code

Using it

• “Analyze this app for Bengali localization.”
• “Localize the onboarding namespace to Japanese and keep the existing terminology.”
• “Review the French locale for naturalness — I think it reads like a translation.”
• “Why does the Arabic build show the wrong plural form for 3 items?”

Limitations

Practical Localizer is instruction-driven, not a translation engine, and it does not claim perfect or native-quality output.

• It is not a replacement for a native reviewer. For a product where the language is the product, it is a first pass that makes human review cheaper and better targeted
• Quality varies by language, by how much context the repository carries, and by the agent running it
• Low-resource languages and specialized domain vocabulary are where it is weakest — and where its confidence levels matter most
• It reads the repository; rendering and runtime data are outside what it can observe, so UI fit findings are flagged as potential rather than confirmed
• Without web access it relies on application context, existing translations and the glossary you supply — and says so
• An absent finding is not proof that the localization is correct