Flow i18n

Internationalization - localization, translations. Use when adding languages.

install

source · Clone the upstream repo

git clone https://github.com/SylphxAI/flow

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/SylphxAI/flow "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/i18n" ~/.claude/skills/sylphxai-flow-i18n && rm -rf "$T"

manifest: .claude/skills/i18n/SKILL.md

source content

i18n Guideline

Tech Stack

i18n: next-intl
Framework: Next.js

Non-Negotiables

```
/en/*
```
must not exist (permanently redirect to non-prefixed)
Missing translation keys must fail build
No hardcoded user-facing strings outside localization
Translation bundles must be split by namespace or route (no monolithic language files)

Context

Internationalization isn't just translation — it's making the product feel native to each market. Bad i18n is obvious to users and signals that they're second-class citizens. Good i18n is invisible.

Consider: dates, numbers, currency, pluralization, text direction, cultural norms. Does the product feel like it was built for each locale, or does it feel like a translation of an English product?

Driving Questions

What would make the product feel native to a non-English user?
Where do translations feel awkward or machine-generated?
What cultural assumptions are baked into the UX that don't translate?
How painful is the translation workflow for adding new strings?
What locales are we missing that represent real market opportunity?
Where do we fall back to English in ways users would notice?
How large are the translation bundles, and what's being sent to the client?

Bundle Constraints

No monolithic language files — split by namespace (
```
common
```
,
```
auth
```
,
```
dashboard
```
, etc.)
Server Components for translations wherever possible — client bundles must not include translations that could stay on server
Each route should load only its required namespaces
Measure client bundle size impact of translations