Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/phuonghx/aim-cli/i18n-localizationnpx skills add phuonghx/aim-cli --skill i18n-localizationgit clone --depth 1 https://github.com/phuonghx/aim-cliWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00073 | $0.00997 |
| Opus 5 | $0.00036 | $0.00498 |
| Sonnet 5 | $0.00015 | $0.00199 |
| Haiku 4.5 | $0.00007 | $0.00100 |
Grade A, and why
i18n-localization scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured yesterday.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 150 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Internationalization and Localization
Two related jobs sit behind multi-language support:
- Internationalization (i18n) -- building the app so it can be translated: no baked-in text, locale-aware formatting, layouts that flex.
- Localization (l10n) -- the per-language work: the actual translations and regional conventions.
A locale pairs a language with a region (en-US, tr-TR, ar-EG). RTL refers to scripts that flow right to left, such as Arabic and Hebrew.
Is it worth doing here?
Reach for i18n early when the audience is plausibly multilingual; treat it as optional for throwaway or single-market work.
- Worth it up front -- public sites, commercial SaaS, anything aimed at more than one country.
- Judgement call -- internal tooling, apps that are single-region today but may expand.
- Skip for now -- prototypes and personal one-offs.
Retrofitting i18n is painful, so when in doubt, structure for it from the start.
Wiring it into common stacks
React with react-i18next
import { useTranslation } from 'react-i18next';
export function Greeting() {
const { t } = useTranslation();
return <h1>{t('greeting.heading')}</h1>;
}
Next.js with next-intl
import { useTranslations } from 'next-intl';
export default function LandingPage() {
const t = useTranslations('Landing');
return <h1>{t('heading')}</h1>;
}
Python with gettext
from gettext import gettext as _
print(_("Welcome aboard"))
Laying out catalog files
Split catalogs by language, then by feature so files stay small and merge-friendly:
locales/
├── en/
│ ├── common.json
│ ├── auth.json
│ └── errors.json
├── tr/
│ ├── common.json
│ ├── auth.json
│ └── errors.json
└── ar/ # right-to-left
└── ...
What to do, and what to avoid
Do
- Reference every string through a key, never the literal text.
- Scope keys by feature or screen.
- Express plurals through the i18n layer rather than ad-hoc
ifchecks. - Format dates and numbers per locale via the
IntlAPIs. - Account for RTL from day one.
- Use ICU message syntax for anything with variables or plurals.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- yesterday First seen · 150 lines · 73 tokens per session scan A d3205d722d50
i18n-localization is a skill published in the GitHub repository phuonghx/aim-cli (1 stars, last pushed 2mo ago), licensed MIT. It adds 73 tokens to every session and 997 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
localization-design
Design for multiple languages, writing directions, and cultural contexts — text expansion, RTL mirroring, and locale formats. Use when shipping beyond one locale. For the words themselves, use ux-writing (designer-toolkit).
nature-reader
Build full-paper Chinese-English side-by-side, figure/table-aware, source-grounded Markdown readers for journal or conference papers from PDF, DOI, arXiv, publisher HTML, or pasted text. Use whenever the user asks to translate or read a paper, make 中英文对照/原文对照/全文翻译解读, extract figures or tables into the right positions…
code
Use BEFORE generating, refactoring, reviewing, or debugging code. Trigger phrases include "write a function/script/class for X", "review this code/diff/PR", "refactor this", "debug this error", "is this implementation correct", "what's wrong with this code", "improve this code", "translate from X to Y", or any prompt…
nature-polishing
Polish, restructure, or translate academic prose into Nature-leaning English using writing-strategy principles, curated Nature/Nature Communications article patterns, and phrase-level support from Academic Phrasebank. Use whenever the user asks to polish a manuscript paragraph, abstract, introduction, results…
hs-release
Cut a core Hindsight release (vX.Y.Z) and open the changelog + blog PR. Use when asked to cut/start a release, bump the version, or publish a new Hindsight version.
hns-oss-docs-readme-sync
README 4-file synchronization procedure for the oss-docs harness: Korean README.ko.md as primary source, en/ja/zh derivation, the shared language-switcher header contract, section-order parity checklist, and the manual verification recipe (no linter exists for READMEs). Loaded by the content-author and…