Bug Report: Navigation bootstrap keeps source locale slug and causes locale confusion

[sayedbs]

Summary

When creating a new localized Navigation entry using Bootstrap from another locale (example: bootstrap en-GB from de-DE), the plugin copies the source slug as-is (navigation-de-DE) instead of generating or enforcing a locale-appropriate slug (navigation-en-GB).
This leads to confusing behavior in admin and can break expected locale/default-locale workflows.

Environment

• Strapi: v5 (project uses Strapi 5)
• Plugin: strapi-plugin-navigation (VirtusLab)
• Database: PostgreSQL
• OS: macOS (Darwin)

Expected behavior

• Bootstrapping a new locale should either:
  • auto-generate locale-compatible slug for target locale, or
  • enforce manual slug update before publish, or
  • show a clear warning that source slug is copied unchanged.

Actual behavior

• Bootstrapping en-GB from de-DE keeps slug navigation-de-DE.
• Entry is still accepted/published in some cases.
• Later, locale switching/default-locale changes produce confusing navigation behavior.

Reproduction steps

1. Open Navigation plugin.
2. Select an existing navigation in locale de-DE with slug navigation-de-DE.
3. Create localization for en-GB using Bootstrap/Copy from de-DE.
4. Observe slug in new locale.
5. Save/Publish.

Observed result

• New en-GB localized entry keeps source slug navigation-de-DE.

Why this is problematic

• Slug no longer matches target locale semantics.
• Teams assume bootstrap creates target-locale-safe slug.
• Can introduce hard-to-debug behavior in multilingual setups, especially when changing default locale.

Suggested fix

1. During localization bootstrap:
   • attempt slug transformation from source locale suffix to target locale suffix, OR
   • require user to confirm/change slug before save.
2. Add validation/warning:
   • if localized entry locale is en-GB but slug ends with de-DE, show warning.
3. Improve UX text:
   • explicitly state that bootstrap duplicates slug unchanged (if this is intentional).

Impact

• Medium to High for multilingual production projects.
• Causes configuration drift and confusing admin behavior over time.

Additional notes

• This issue was reproduced across two PostgreSQL databases with different data states.
• Main trigger remains the bootstrap-copy behavior preserving source slug in target locale.

Strapi version and packages

  "dependencies": {
    "@strapi/plugin-seo": "^2.0.8",
    "@strapi/plugin-users-permissions": "^5.16.0",
    "@strapi/provider-upload-cloudinary": "^5.16.0",
    "@strapi/strapi": "^5.16.0",
    "@strapi/utils": "^5.16.0",
    "axios": "^0.27.2",
    "cloudinary": "^2.6.0",
    "date-fns-tz": "^1.3.7",
    "pg": "^8.14.1",
    "pg-connection-string": "^2.6.4",
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "react-redux": "^9.2.0",
    "react-router-dom": "^6.0.0",
    "strapi-plugin-bootstrap-admin-user": "^1.0.8",
    "strapi-plugin-navigation": "^3.0.11",
    "strapi-plugin-preview-button": "^3.0.1",
    "strapi-plugin-webtools": "^1.5.0",
    "strapi-v5-redirects": "^1.0.3",
    "styled-components": "^6.0.0",
    "webtools-addon-sitemap": "^1.3.0",
    "yup": "^1.3.2"
  },

[sayedbs]

Note that this project is migrated from Strapi 4

[cyp3rius]

Thank you for reporting @sayedbs. Have you applied all the migration scripts as mentioned in the Migration Guide?

Also, valuable information could be found in this issue.