i18n-check

i18n Check

Analyze code for internationalization issues, with emphasis on understanding impact and user experience.

Philosophy

This is not about flagging every hardcoded string. It's about asking:

"If someone in Cairo, Munich, or Tokyo uses this, will it work for them?"

i18n issues aren't just bugs—they're barriers. A date shown as "12/05/2024" is ambiguous to most of the world. A text field that truncates German words breaks the experience. A layout that assumes left-to-right excludes 400 million RTL readers.

Scope

The user may specify a file path, glob pattern, or directory. If not specified, ask what they'd like to check.

Config Integration

Before starting, follow the migration preflight in references/config-migration.md, then read .assistant-config.md from the project root.

If it exists:

1. Read scope decisions and acknowledged findings
2. If i18n is "out of scope": Skip the check entirely, output brief note:

   ## i18n Analysis: [path]
   
   **Skipped:** i18n checks disabled per project config (US-only)
   To re-enable, update .assistant-config.md
   

3. If in scope: Skip acknowledged findings, note them in output
4. Note at the top of output: "Config loaded: .assistant-config.md"

Process

1. Read and Understand

First, read the code to understand:

• What does this component/file do?
• Is this user-facing or internal tooling?
• What kind of content does it display? (dates, numbers, text, forms)
• Is there existing i18n infrastructure? (react-intl, i18next, etc.)

2. Trace the User Experience

Think through what users see:

• Where do dates/times appear? How are they formatted?
• Where does text appear? Can it expand without breaking?
• What direction does the layout assume?
• What do forms ask for? Are fields US-specific?

3. Assess Impact by Audience

Critical (breaks functionality):

• Date formats that cause confusion (12/05 - December 5 or May 12?)
• Forms that require US-only fields (State, ZIP) with no alternatives
• Layouts completely broken in RTL