agentleFS
castle-xcastle-x/skills-x/skills/go-i18n/SKILL.md

go-i18n

Skill18 starsChanged 7 months agoMITView on GitHub

Use when defining or updating Go CLI i18n rules in this repo, especially around locale files, env-based language selection, and key naming.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 4 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use lowercase + underscores with category prefixes:

    line 59
  2. Distinctive:

    Rule: Never mix Chinese and English in the same string.

    line 70
  3. Distinctive:

    Add the same key to both locale files:

    line 74
  4. Very specific:

    Use i18n.T / i18n.Tf in Go code.

    line 77
  5. Very specific:

    Add a skill_<skill-name> key to both locale files.

    line 85
  6. Distinctive:

    Only adding a key in one locale file

    line 112

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Go CLI i18n

Overview

This skill documents the Go CLI i18n rules used in this repo, including language detection, locale files, and key naming conventions.

When to Use

  • You add or edit any user-facing CLI string in cmd/skills-x
  • You need to add a new skill description for list output
  • You are troubleshooting mixed language output or missing translations

Architecture Snapshot

  • i18n runtime: cmd/skills-x/i18n/i18n.go
  • Locale files: cmd/skills-x/i18n/locales/zh.yaml, cmd/skills-x/i18n/locales/en.yaml
  • Embed: //go:embed locales/*.yaml (locales are embedded at build time)

Language Selection

Priority order in detectLanguage():

  1. SKILLS_LANG
  2. LANG
  3. LC_ALL
  4. Default: zh

Normalization uses prefix matching:

  • zh, zh_CN, zh_TW → zh
  • en, en_US → en
  • Unsupported → zh

Using i18n in Go

Initialize once (early in main):

import "github.com/castle-x/skills-x/cmd/skills-x/i18n"

i18n.MustInit()

Translate strings:

title := i18n.T("list_header")
msg := i18n.Tf("init_success", skillName)

Missing keys return the key itself (useful for spotting gaps).

Key Naming Conventions

Use lowercase + underscores with category prefixes:

  • app_ app metadata
  • cmd_ command descriptions/flags
  • list_ list output
  • init_ init output
  • err_ error messages
  • cat_ category names
  • skill_ skill descriptions
  • meta_ meta warnings

Rule: Never mix Chinese and English in the same string. Use two locale keys instead.

Adding New Strings

  1. Add the same key to both locale files:
    • cmd/skills-x/i18n/locales/zh.yaml
    • cmd/skills-x/i18n/locales/en.yaml
  2. Use i18n.T / i18n.Tf in Go code.
  3. Rebuild (make build) to embed the updated YAML.
  4. Test:
    • SKILLS_LANG=zh ./bin/skills-x list
    • SKILLS_LANG=en ./bin/skills-x list

New Skill Description

Add a skill_<skill-name> key to both locale files. The list view reads descriptions from i18n, not from the skill file.

Example

# locales/en.yaml
init_success: "Installed: %s"

# locales/zh.yaml
init_success: "安装成功: %s"
fmt.Println(i18n.Tf("init_success", skillName))

Quick Reference

ItemValue
Locale filescmd/skills-x/i18n/locales/{zh,en}.yaml
Initi18n.MustInit()
Translatei18n.T, i18n.Tf
Language prioritySKILLS_LANG > LANG > LC_ALL > zh

Common Mistakes

  • Only adding a key in one locale file
  • Hardcoding mixed-language strings
  • Forgetting to rebuild after YAML changes
  • Formatting with fmt.Sprintf before calling i18n.Tf

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.