What does this skill do, and when should you use it?
This is one of 18 Agent Skills bundled in the OpenChamber repository (a desktop and web interface for the OpenCode AI agent), located at .agents/skills/locale-ui-patterns/SKILL.md. It is not an executable tool but a mandatory i18n working convention: all UI text must flow through @/lib/i18n, and every new translation key must contain a real translation in all nine language dictionaries right away. The skill also covers key naming style, reactive string resolution in React, parameter placeholders, and plural handling. Load it when contributing to OpenChamber or when an AI agent modifies its user-facing strings.
The skill defines and enforces a translation-key workflow: add or reuse a key in packages/ui/src/lib/i18n/messages/en.ts; immediately write the fully translated value into every non-English dictionary (es, fr, ko, pl, pt-BR, uk, zh-CN, zh-TW); resolve strings via t('key') from useI18n() inside render/hook scope; use {name}-style placeholders only for real values, never grammar fragments like {suffix}, with separate complete-message keys for plurals and optional clauses; it also lists untranslatable literals (OpenChamber, MCP, SSE, file paths, etc.) and six completion criteria. It runs no scripts — it constrains agent behavior purely through instructions.
- A contributor opening a PR to OpenChamber who added a button or settings label and must sync translations into nine language dictionaries per project rules.
- An AI agent batch-editing OpenChamber UI text, where you want to prevent hardcoded English in components and lazy English paste-ins in es.ts/zh-CN.ts.
- A maintainer reviewing others' changes, using the skill's completion criteria (no hardcoded English, full dictionary coverage, reactive resolution) as a checklist.
- Adopting patterns — key naming (location+role+meaning), plural complete-message handling, label(locale) language-picker labels — in similar multilingual React projects.
How do you install this skill?
- This is a static source review; nothing was executed, so reliability and effectiveness conclusions carry low confidence.
- The skill mandates immediate full translation for every locale; if a language cannot be translated, the skill requires explicit disclosure rather than pasting English placeholders.
- The skill has no version number or changelog; updates must be manually checked against the actual i18n implementation in packages/ui.
- Publisher is not verified by the FollowSkills registry; identity is unknown (not suspicious).
- The 'user-facing strings' trigger scope in the description is interpretive, so both false triggers and misses are possible.
- Local filesystem
The skill ships with the openchamber/openchamber repository (MIT licensed). Clone the repo and copy the .agents/skills/locale-ui-patterns/ directory into your own .agents/skills/ directory (Claude Code recognizes that in-repo location), or use it in place within the repository. The repo provides no dedicated install script or install command for individual skills; consult your client's documentation for exact loading steps.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/openchamber/openchamber.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/.agents/skills/locale-ui-patterns" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Add an aria-label for the language option in settings, following the locale-ui-patterns skill, and translate it into all dictionaries.
Simply let your agent perform any UI-copy task inside the OpenChamber repo — the description field lets the client load it in relevant scenarios. You can also trigger it explicitly, e.g.: "Add an aria-label for the language option in settings, following the locale-ui-patterns skill, and translate it into all dictionaries." Then verify per the skill's flow: new key in en.ts, real translations in every non-English dictionary, t() called inside render scope, no locale fields in broad stores, no full-app remount on language change.
What are this skill's strengths and limitations?
- Rules are extremely concrete and enforceable: good/bad code examples, an explicit list of forbidden placeholders ({suffix}, {plural}…), and unambiguous completion criteria leave little room for agents to cut corners.
- It closes the classic loophole: there is no 'leave it in English for now' convention — if a language can't be translated, the agent must say so instead of silently pasting English.
- Pure instruction-based skill with no scripts or runtime dependencies; any Agent Skills-compatible client can use it directly.
- Tightly coupled to OpenChamber's code structure (@/lib/i18n, packages/ui paths, useI18n); reusing it elsewhere requires rewriting paths and conventions first.
- Documentation only — no automated lint/check script is included, so compliance depends on agent discipline or manual review.
- The set of nine target languages is fixed; supporting a new locale requires extending the convention yourself.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| Locale UI Patterns — OpenChamber UI Localization Rules this page | 61 · Recommended | ★ 12k | 11d ago | MIT |
| i18n Workflow | 53 · Use with care | ★ 34k | 11d ago | Apache-2.0 |
| cmux Localization Rules & Audit Skill | 56 · Use with care | ★ 28k | 11d ago | NOASSERTION |
| OpenChamber UI/API Decoupling Skill | 58 · Recommended | ★ 12k | 11d ago | MIT |
| React Flow Node Builder ✓ Microsoft · Official | 52 · Use with care | ★ 2.7k | 3mo ago | MIT |
How did FollowSkills review this skill?
Pure documentation-only convention guide: no scripts, network calls, permissions, sensitive data or external effects; data flow is transparent. Deducted for absence of rollback/invalidation guidance and publisher identity unverified, with source attribution resting solely on repository metadata.
Instructions are self-consistent and explicit (no English placeholders, complete-message keys); abnormal input (untranslatable string) requires explicit user disclosure, giving good failure feedback. Deducted because this is a static read: no test evidence covering the i18n key paths, and rule enforceability was not reproduced.
Description clearly lists trigger scenarios (UI text, buttons, aria labels, toasts, etc.); boundaries are precise; the product itself ships zh-CN/zh-TW so environment fit is good. Deducted for no declared non-fit ranges (backend strings, logs) and trigger precision relying on interpretation of 'user-facing strings'.
Well-layered structure: core rule, required flow, component rules, key style, parameters, completion criteria, with good/bad examples; MIT license clear. Deducted for no per-skill version or changelog, no stated maintenance ownership or update path, and the 'examples not exhaustive' namespace list introducing hidden assumptions.
As a convention skill it prevents hardcoded English and missing translations across 9 locale dictionaries; output is directly usable code changes. Deducted for no representative-output verification, effectiveness depending on model compliance, and no executed or third-party evidence of benefit.
Referenced paths (packages/ui/src/lib/i18n/messages/*.ts) are auditable in the repo and rules are traceable. Deducted because the dictionary files themselves were not in evidence, the completeness claims cannot be independently confirmed, and there is no third-party execution evidence.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →