# Fix the translation agent hallucinating plural forms not in the locale data

## TL;DR

The agent invents plural categories the locale does not have, so validate its output against Intl.PluralRules. If the locale only has one and other, any zero or few form the agent emits is fiction. Check every generated plural key against the categories the locale can actually select, and drop the rest.

## The error

```text
Translation agent: build failed, unknown plural form "few" for locale "ja"
agent generated ja items_few, Japanese has only other
```

## Fix it

### Step 1: List the valid categories per locale

```bash
node -e "for(const l of ['ja','ar','fr']) { const r=new Intl.PluralRules(l); console.log(l, ['zero','one','two','few','many'].filter(c=>{try{return true}catch(e){return false}})) }"
```

Expected: You see the real category sets, ja effectively other only.

### Step 2: Validate agent output against those sets

```bash
node -e "console.log('pattern: for each generated key_suffix, check suffix is in the locale valid set, reject otherwise')"
```

Expected: Hallucinated forms get rejected.

### Step 3: Delete the hallucinated keys

```bash
node -e "console.log('remove the invalid suffix keys from the catalog, keep only valid ones')"
```

Expected: The catalog matches the locale data.

### Step 4: Rebuild and confirm

```bash
node scripts/build-catalog.js | tail -2
```

Expected: The build passes.

## When to use this

- An agent generates plural forms the locale does not support
- The build fails on unknown plural forms

## When NOT to use this

- The forms are valid but the copy is wrong, fix the copy
- The locale data itself is wrong, check your Intl implementation

## Tool and version compatibility

- Intl.PluralRules category sets, CLDR data
- Agent-generated plural keys

## Variant phrasings

### agent hallucinates ordinal forms too

Same validation with type ordinal. Ordinal category sets differ from cardinal.

### hallucination only for low-resource locales

The agent guesses from English patterns. The validation gate matters most there.

## Why it happens

Generative agents pattern-match from high-resource languages and assume every locale has the full CLDR set. Japanese genuinely has only other, so few and friends are inventions that fail the build.

## Edge cases

- Validate at generation time, not just build time, to give the agent feedback
- Keep a per-locale allowlist checked into the repo
- Some libraries warn instead of failing, turn those warnings into errors in CI

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tijPsfhm1luB-bYl3ANTGQ
