Strapi I18n Bug: Non-Localized Fields Cause Problems

by Admin 53 views
Strapi i18n Bug: Non-Localized Fields Cause Unintended Publishing and UI/API Desynchronization

Introduction

Hey guys, this article dives deep into a nasty bug in Strapi v5 related to internationalization (i18n) when you're using non-localized fields. We'll explore two primary issues: the unexpected linking of save/publish actions across locales and the resulting desynchronization between the Strapi admin UI and the public API data. This bug can lead to some serious headaches, including unintentionally publishing content and serving stale data to your users. We'll break down the problems, how to reproduce them, and what to expect. Let's get started!

Bug 1: Save/Publish Actions Affect All Locales

Bug Description

When you're building a multi-language website or application with Strapi and have i18n enabled on a collection type, things can go sideways when you introduce non-localized fields. The core issue is that the save and publish states of all your locales get intertwined. Imagine you've got an "Event" content type with fields like title (localized) and description (non-localized). The bug manifests when you modify and save an event in one language (e.g., English). Instead of just marking the English version as modified, Strapi incorrectly marks all other locales (like German) as modified too. And the kicker? If you then publish the English version, it automatically publishes the German version as well, even if you didn't want to. This behavior goes against the expected functionality and purpose of localized content management.

Expected Behavior

Let's be clear on what should happen:

  • When you change a localized field (like the title) in one language, only that language version should be marked as modified. Other languages should remain in their existing state (published, draft, etc.).
  • The "Publish" button should only publish the specific locale you're currently working on.
  • If you want to publish all languages at once, the "Publish multiple entries" option should be the only way to do it. It's like having a dedicated button for a global update, and this is what we expect.

In essence, saving and publishing changes in one language shouldn't inadvertently trigger actions in others. This level of control is crucial for managing content across multiple locales effectively.

Bug 2: UI/API Desynchronization

Bug Description

This is where things get even worse, guys! The bug in the previous section sets the stage for a nasty problem: the Strapi admin UI and the public API get out of sync. After the unintended publish action (triggered by Bug 1), the admin UI might show that a specific language version is published (green "Published" status), but the API might still be serving the old, stale content for that language. This creates a really confusing situation because the UI thinks everything is live and up-to-date, but your users are seeing outdated information. This desynchronization makes it almost impossible to manage your content correctly, and this bug is a serious deal-breaker.

Expected Behavior

Here's what needs to happen to fix this:

  • The admin UI must be the source of truth. If the UI says something is published, the API has to serve the exact same data shown in the admin panel.
  • The UI and the API data should never be out of sync. It's the most fundamental principle for any content management system.

Basically, the data displayed in the Strapi admin and the data delivered through the API must be exactly the same. Without this consistency, managing content becomes a nightmare, and your users suffer.

Steps to Reproduce the Bugs

Prerequisites

To see these issues in action, you'll need the following:

  • Node.js: v18.x - v22.x (v20 LTS recommended)
  • Git
  • npm

1. Clone the Repository and Install Dependencies

First, you'll clone the provided repository, which has a minimal Strapi v5 project that's been specifically set up to reproduce the bugs. This project uses SQLite to keep things simple, so you won't need to set up an external database. Here's how to clone the repo and get the dependencies installed:

git clone https://github.com/EemeliSurakkaBrink/strapi-i18n-bug-report strapi-i18n-report
cd strapi-i18n-report
npm ci

2. Run the Strapi Application

Next, you'll start up the Strapi application in development mode:

npm run develop

Once Strapi is running, you'll need to create your admin user at http://localhost:1337/admin.

3. Project Configuration

The project is pre-configured to make it easy to reproduce the bug. The important parts are in package.json and the Event content type configuration. Check out the setup:

{
  "name": "strapi-i-18-n-report",
  "dependencies": {
    "@strapi/plugin-cloud": "5.30.0",
    "@strapi/plugin-users-permissions": "5.30.0",
    "@strapi/strapi": "5.30.0",
    "better-sqlite3": "11.3.0",
    "react": "^18.0.0",
    "react-dom": "^18.0.0",
    "react-router-dom": "^6.0.0",
    "styled-components": "^6.0.0"
  },
  "engines": {
    "node": ">=18.0.0 <=22.x.x",
    "npm": ">=6.0.0"
  }
}

4. Add a New Locale in the Admin

You'll need to create a second locale to see the bug in action:

  1. Go to Settings → Internationalization.
  2. Click Add new locale.
  3. Select German (de) from the dropdown and click Save.

Now, you can create an "Event" entry in the Content Manager and try translating it into German to see the issues related to the non-localized description field.

Detailed Bug Reports

Bug Report 1: Save/Publish Actions Affect All Locales

Title: Bug(i18n): Save/Publish actions affect all locales when a non-localized field is present

Description:

When i18n is enabled and a collection type contains at least one non-localized field, the save and publish states of all locales become linked. Modifying and saving one locale incorrectly marks all other locales as "modified." Consequently, publishing one locale automatically publishes all other locales for that entry. This behavior contradicts the intended purpose of the "Publish multiple entries" option.

Steps to Reproduce:

  1. Create a new Event entry in the default English (en) locale.
  2. Provide values for both title and description. Save and publish the event.
  3. From the right-hand sidebar, add a German (de) translation. Provide a German title. Save and publish it.
  4. Go back to the English locale and edit the localized title field. Click save.

Actual Behavior:

After saving the change in the English locale, both the English and German locales are immediately marked as "modified."

If you click publish on the English entry, the German entry is also published simultaneously.

Expected Behavior:

  • Saving a change to a localized field (like title) in English should only modify the English locale.
  • Clicking publish on a single locale should only publish that locale. Other locales should not be affected.
  • The "Publish multiple entries" option should be the only way to publish all locales at once.

Bug Report 2: UI Shows Locale as 'Published' but API Data is Stale

Title: Bug(i18n): UI shows a locale as 'Published' but the API serves stale data after a linked publish

Description:

This bug results directly from Bug #1. After a linked publish (one locale publishing forces another), the UI incorrectly shows the second locale as "Published." However, the public API continues to serve the old content, causing a desynchronization between the admin panel and live data.

Steps to Reproduce:

  1. Trigger Bug #1.
  2. Make a change to the English title field, then click publish on the English entry.
  3. Verify the German entry now shows a green "Published" status and displays the new description text (since it's non-localized).
  4. Make a GET request to the public API to fetch the German version of the entry (e.g., GET /api/events/1?locale=de).

Actual Behavior:

The API response for the German locale contains the old data. The admin UI for the German locale shows a "Published" status, but it is not updated. The "Publish" button is disabled.

Workaround Steps:

  1. Navigate to the German locale in the Content Manager.
  2. Make a small, arbitrary change to the localized title field (e.g., add a space).
  3. Click publish.

Expected Behavior:

The UI status must be the source of truth, and the API must serve the exact data shown in the admin panel.

The UI and the API data should never be desynchronized.

Conclusion

These i18n bugs in Strapi can be a real pain, especially when you're managing content in multiple languages. They can lead to confusion, incorrect data being displayed, and a frustrating user experience for both content editors and website visitors. It's really important that these issues are addressed to ensure Strapi's i18n features work as expected, and your internationalized projects run smoothly. Stay tuned for updates and potential fixes!