Content Editing XP

When working with i18n content, even small changes in a field require reprocessing the entire content for translation. This becomes inefficient for large texts or frequent updates. It would be useful to introduce a digest (hash) mechanism per i18n field, allowing plugins and integrations to detect whether content has actually changed. Proposed behavior: Each localized field stores a digest (e.g., hash of content) Digest updates only when the field content changes Plugins (like translation tools) can compare digests to perform incremental translation, skipping unchanged content Benefits: Avoid unnecessary re-translation of unchanged content Reduce API usage and costs for AI translation services Improve performance for large datasets and frequent edits Enable smarter caching strategies for localization workflows Use case: In AI-powered translation workflows, this allows processing only modified fields instead of re-translating entire entries after minor edits. This would improve the ecosystem for translation plugins and localization workflows in Strapi. I’ve been exploring this approach while building a translation plugin https://github.com/l10n-dev/strapi-plugin-ai-translator , and it significantly improves efficiency.

A global search that searches through all content types. Customers using the system have a lot of content and would like to be able to search through it all at once.

please add RTL support , there are many Persian, Arab, Hebrew users using Strapi I don't understand why strapi still doesn't implemented this

see: https://github.com/strapi/strapi/issues/557

I would need a way to set alternativeTexts per language on files in the upload plugin. For now I just built a custom collection, which contains a file and localized alt text. However, I think this is a very common use case and related to i18n plugin, so I just opened as an issue. See: https://github.com/strapi/strapi/issues/10220

Problem Rich text editor doesn't support custom elements. This can be achieved by extending the Rich Text editor or extending Markdown to suit your requirements. eg a link which opens login modal inside running rich text. While plain links are possible, these custom links are only possible if a custom entry can be embedded inside Rich text. Similarly, embedding links which open in a new tab inside a rich text snippet. Solution While creating a rich text field, a setting can be enabled to embed entries and which content types are allowed to embed. Embed can be inline or block level or both.

At the moment the content history will not enable on content types that are based from plugins, a customer (reference ticket id 7420) has requested an enhancement to the current content history feature

The default Rich Text editor has very limited "Rich Text" features. It would be nice to have a full set of features including different font types and colors

I am making a custom rich text field for the front end of my site using Slate. I plan on adding support for @mentions and custom emoji. Since the Rich text (Blocks) editor in Strapi uses Slate, I need to be able to support my custom elements in Strapi. I plan to look into forking Strapi's editor, but being able to just extend the current one would be a lot nicer. I may look into writing a PR for making it extensible myself, but probably not anytime soon since my free time is all tied up with my personal Strapi project. I wanted to submit the idea in case anyone else wants to run with it.

When a user adds a link in the CK5 editor using only keyboard shortcuts, the usual flow is: 1. Press Cmd + K to open the link popup. 2. Press Cmd + V to paste the URL from the clipboard. 3. Sometimes, press Cmd + Enter instead of just Enter. This can accidentally publish the post, which is disruptive and inconvenient. I also found an open Strapi PR that appears to address the same issue by changing the shortcut behavior so Cmd/Ctrl + Enter saves a draft, while Cmd/Ctrl + Shift + Enter publishes instead. The PR was opened on January 28, 2026 and is linked to issue #25165.  https://github.com/strapi/strapi/pull/25283 Would it be possible to implement a similar fix here?