docs/content/docs/02.guide/91.new-features.md (1)

8-26: New feature blurb is clear; only a tiny wording nit

The description and example accurately reflect the new prefix option and correctly point to the options docs. If you care about style, you might vary the repeated “want to use …” phrasing in lines 9 and 11, but that’s purely cosmetic.

src/types.ts (1)

518-526: Clarify prefix typing and adjust code JSDoc for consistency

Two small consistency points around this new field:

• The options docs describe prefix as null | string, while the type here is prefix?: string. In TS configs this means prefix: null will be rejected even though the docs say it’s allowed. Either change the docs to just string or widen the type here to string | null if you want that to be officially supported.
• The code JSDoc above still says “Used for route prefixing…”, but with this option routing may use prefix instead of code when defined. Consider rephrasing to something like “Unique identifier of the locale. Used for route naming and as an argument in i18n utilities; used as the default URL prefix when no custom prefix is configured.”

docs/content/docs/04.api/00.options.md (1)

152-169: prefix option docs are accurate; consider clarifying allowed format

The behavior and example are aligned with the implementation: custom segment for the URL path while route names still use the locale code.

Two possible clarifications to make this harder to misuse:

• Explicitly say the value should be a single path segment without leading/trailing / (e.g. brazil, not /brazil/), since the module prefixes it with / internally.
• Optionally note that prefixes should be unique per locale when using path-based strategies; duplicate prefixes will lead to routes sharing the same URL path even though their names differ.

src/routing.ts (1)

67-79: Locale prefix map wiring looks correct; consider guarding against duplicate prefixes

The buildLocalePrefixes helper and its use in localizeRoutes cleanly introduce per-locale prefixes while preserving existing behavior when prefix is unset/empty.

You might optionally mirror the domain-duplication guard from shouldLocalizeRoutes and log a warning or error if multiple locales share the same non-empty prefix, since that will generate routes with identical paths but different names, which can be surprising in Vue Router. Not critical, but would make misconfigurations easier to catch.

Also applies to: 91-94

test/locale-prefix.test.ts (1)

1-241: Good coverage for locale prefixes; only a minor naming nit

The test suite does a solid job exercising custom prefixes across strategies, children, aliases, trailing slashes, empty prefixes, and mixed configurations. This gives good confidence in the new behavior.

Tiny nit: the “should handle prefix with special characters” case currently uses 'br', which is not really special. Either rename the test description or switch the sample to something like 'br-south' or similar to better reflect the intent.

src/kit/gen.ts (1)

70-78: RouteContext getLocalePrefix integration looks correct; consider constraining prefix format

The introduction of getLocalePrefix and its use in both path and alias localization is consistent:

• Locales with a configured prefix use that value; others fall back to the locale code.
• no_prefix and unprefixed trees still work because shouldPrefix controls whether prefixed vs unprefixed is used.
• Empty prefixes behave as intended via the buildLocalePrefixes logic.

One behavior worth calling out (and possibly guarding against): if a user supplies a prefix containing / (e.g. '/brazil'), join('/', prefix, unprefixed) will yield paths with multiple slashes like '///about'. You may want to normalize or reject such prefixes in one place (e.g. when building the localePrefixes map) and/or document that prefix must be a bare segment without slashes.

Also applies to: 105-123, 145-160, 191-203

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro