agentleFS
launch52-ailaunch52-ai/flutter-template/.claude/skills/i18n/SKILL.md

i18n

Skill2 starsChanged 9 months agoMITView on GitHub

Audit Flutter code for hardcoded strings, write clear user-friendly text following UX guidelines, and migrate strings to i18n files. Use when checking localization, finding hardcoded text, improving string clarity, writing error messages, button labels, or any user-facing text.

We split this skill into the rules it gives an agent

5 rules. 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 36 edited versions we read keep these.

  • 3

    Distinctive

    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:

    Ensure all user-facing text is localized and crystal clear.

    line 9
  2. Distinctive:

    No confusing dialogs: - Never [Cancel] [OK] on a cancel confirmation

    line 27
  3. Very specific:

    Look for: Text('...'), title:, hintText:, label:, SnackBar messages, Dialog content.

    line 64
  4. Distinctive:

    Check each string against ux-writing-guide.md.

    line 68
  5. Very specific:

    Create/update lib/features/{feature}/i18n/{feature}.i18n.yaml with proper strings.

    line 72

“Common” is measured: kept by at least 6 in 10 of the 36 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.

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

i18n - Localization & UX Writing

Ensure all user-facing text is localized and crystal clear. Every string should be understandable by a 10-year-old or non-native English speaker.

When to Use This Skill

  • Checking for hardcoded strings
  • Writing or improving user-facing text
  • Creating error messages, button labels, confirmations
  • Migrating strings to i18n files
  • Reviewing string quality

Quick Reference

The Golden Rules

  1. Be specific, not vague - "Could not save photo" not "Error occurred"
  2. Use plain words - "Sign in" not "Authenticate"
  3. Buttons complete "I want to ___" - "Delete photo" not "OK"
  4. Errors say what to do - "Check your connection and try again"
  5. No confusing dialogs - Never [Cancel] [OK] on a cancel confirmation

File Structure

lib/
├── core/i18n/
│   ├── common.i18n.yaml        → t.common.*
│   └── translations.g.dart     → Generated
└── features/{feature}/i18n/
    └── {feature}.i18n.yaml     → t.{feature}.*

Commands

# Audit for hardcoded strings
dart run .claude/skills/i18n/scripts/check.dart --audit

# Audit specific feature
dart run .claude/skills/i18n/scripts/check.dart --audit auth

# Generate missing i18n files
dart run .claude/skills/i18n/scripts/check.dart --generate

# Regenerate translations
dart run build_runner build --delete-conflicting-outputs

Workflow

1. Audit

dart run .claude/skills/i18n/scripts/check.dart --audit {feature}

Look for: Text('...'), title:, hintText:, label:, SnackBar messages, Dialog content.

2. Evaluate & Improve

Check each string against ux-writing-guide.md. Use patterns from examples.md.

3. Add to i18n File

Create/update lib/features/{feature}/i18n/{feature}.i18n.yaml with proper strings.

4. Replace in Code

// Before: Text('Welcome back')
// After:  Text(t.auth.login.title)

5. Regenerate

dart run build_runner build --delete-conflicting-outputs

Guides

GuideUse For
setup-guide.mdInitial slang setup, build.yaml, file structure
ux-writing-guide.mdUX writing principles, patterns
examples.mdBefore/after examples by scenario

Checklist

  • A 10-year-old would understand it
  • Names the specific thing (photo, message, account)
  • If error: says what happened AND what to do
  • If button: completes "I want to ___"
  • If confirmation: buttons clearly show outcomes
  • No jargon (credentials, authenticate, invalid, terminate)

Related Skills

  • /a11y - Accessibility labels (add to accessibility: section in i18n files)

Download now (ZIP)

  • Other versions45 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 45

    1. lobehub/lobe-chat★ 83ksame name
    2. lobehub/lobehub★ 83ksame name
    3. iOfficeAI/AionUi★ 34ksame name
    4. massCodeIO/massCode★ 7.1ksame name
    5. leookun/cursor-byok★ 3.2ksame name
    6. Pixeval/Pixeval★ 3.2ksame name
    7. akiver/cs-demo-manager★ 2ksame name
    8. d-kimuson/claude-code-viewer★ 1.3ksame name
    9. OpenClaudia/openclaudia-skills★ 723same name
    10. huoshen80/ReinaManager★ 706same 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.

  • Used alongsideProjects 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-LtdSkill

      oss-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-LtdSkill

      pr-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

    • volovelySkill

      pr-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

    • xfstudioSkill

      graphql

      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

    • MicrosoftSkill

      state-management

      CoreAI Sandbox's simplified 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 3 projects that use this

    • MicrosoftSkill

      bump-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
  • In this repository27 other files it gives its agents.

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

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.