# Fix the extraction agent failing to resolve locale aliases in next.config

## TL;DR

The agent reads locales from one place but your aliases live in next.config, so teach it to read the config. Locale aliases like mapping en to en-US are config, not convention, and the agent guessed wrong. Point the agent at the next.config i18n block and resolve aliases from there.

## The error

```text
Extraction agent: failed to resolve locale alias "en"
next.config.js maps locales: ["en-US", "en-GB"], defaultLocale: "en-US"
```

## Fix it

### Step 1: Show the agent the real config

```bash
grep -n -A 8 "i18n" next.config.js | head -12
```

Expected: You see the locales list and defaultLocale the agent must use.

### Step 2: Configure the agent to read next.config

```bash
node -e "console.log('set the agent locale source to next.config.js i18n.locales instead of its default guess')"
```

Expected: The agent reads the authoritative list.

### Step 3: Map aliases explicitly where the agent needs them

```bash
node -e "console.log('provide alias map: en to en-US, derived from defaultLocale, not guessed')"
```

Expected: Aliases resolve deterministically.

### Step 4: Re-run extraction for every locale

```bash
node scripts/extract-strings.js | tail -3
```

Expected: All configured locales extract without alias errors.

## When to use this

- Extraction fails on locale aliases defined in next.config
- The agent guesses locale lists instead of reading config

## When NOT to use this

- The aliases are wrong in next.config itself, fix the config
- Locales resolve but strings are missing, different problem

## Tool and version compatibility

- Next.js i18n routing config, next.config.js
- Any extraction agent with configurable locale sources

## Variant phrasings

### aliases in a custom i18n config file

Same fix. Point the agent at whatever file is authoritative, not its defaults.

### domain-based locales

Domains add another alias layer. Resolve domain to locale from the same config block.

## Why it happens

Next.js lets the config define the locale list, the default, and domain mappings, but extraction agents often assume a locales folder convention. When the two disagree, aliases the config defines look unresolvable to the agent.

## Edge cases

- next.config can be a function, the agent must evaluate it not just parse it
- Middleware can add runtime aliases the config does not show, document those
- Keep one source of truth, config, and make everything read it

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_ULXOQZ0LJ3c17_AxNFn4Qg