WordPress Translation Gets Harder Because of AI

Getting good translations of the WordPress interface is harder than ever, and AI is to blame. Remember that you can listen this program from:     ## Program transcript Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community. In this episode, you’ll find the **information from October 12 to 18, 2026**. Getting good translations of the WordPress interface is harder than ever, and AI is to blame. Machine translation has helped for twenty years, but now many developers use models like ChatGPT or Claude to translate their plugins and themes in bulk into languages they don’t speak, and expect volunteers to review the output, which takes far more effort than generating it. Each locale team accumulates thousands of pending strings every week, and the usual outcome is spot-checking and approving or rejecting in bulk, with tools that only handle one screen at a time. At the same time, requests for the project translation editor role have skyrocketed: over the past six months, the team has gone from receiving more per day than it used to per week, and developers aren’t asking for one or two locales, but for ten or twenty. There are three lines of work. Adapt each locale’s style guide so models can use it, in English and in Markdown; create an automated translator role that can contribute translations but can’t approve or edit those of others, and keep unverified content out of the translation memory; and change the team’s mission, which in addition to training translators will have to teach developers to use machine translation wisely and to internationalize their code properly. The comments add nuance. For example, one proposal is to limit imports to one hundred strings until an editor approves them; another is that only editors should be able to import and pull requests from the blog; some note that many developers think they need the role to get their translations approved; and others point out that the real incentive is directory visibility, and that an automatic glossary is hard in German because of its compound words. The most elaborate proposal is not to ban anything, but to make automation visible. The author would declare when importing that they used AI and agree that the strings be marked as unreviewed; editors could release them in bulk or reject them with a single action; they would not enter the translation memory; and users would see the notice before installing, with the option to choose English or disable automatic translations. From Japan, they report that their team reviews only the first strings and leaves change requests, and that their style guide works because many people already feed it to automated tools, with a request form limited to three locales as an idea. **Gutenberg 24.2** is now available, with Notes as the star. They now live in a margin alongside the canvas, so they stay visible while you change blocks or settings, can be minimized or hidden, a deleted note can be undone, and what you’re writing isn’t lost when switching blocks. The Navigation block gains a single search that covers pages, posts, categories, and tags at once, and the Gallery can sort its images and apply a shared duotone. Design tools keep spreading across dozens of blocks: minimum width and height, shadows, duotone, and image or gradient backgrounds. For developers, the most important change is that *React 19* is now enabled by default, except on sites with a theme or plugin known to have problems, which stay on *React 18*. This reverses the postponement in WordPress 7.1, and the team asks people to test plugins and themes that use React; it can be disabled in the Experiments area. **Feature Notifications**, the project to build a unified notification system for WordPress, is back to life after more than three years stalled: its last version, 0.2.0, dates from April 2023. Jonathan Bossenger, who had to step away in 2023 and has picked the project back up, audited the code and published a plan to reach a 0.3.0, which would be the first truly functional version, able to create, store, display, and dismiss notifications, with the goal of shipping it on December 1, alongside the last release candidate of WordPress 7.2. The foundations are solid, with data models, channel registration, the database schema, and the notification center UI in the admin bar, but the system isn’t connected end to end. The persistence layer is still unimplemented, the REST API returns empty responses, dismissing a notification saves nothing, and the REST controller tests are disabled. The plan is split into phases that can move in parallel: sorting the open pull requests, building the minimum product with schema migration, repositories, a PHP API for emitting notifications, REST endpoints with a permissions model, persistent dismissal, and a WP-CLI command to generate test notifications. Security and bug fixes come afterward. It will be published as a GitHub release and as a plugin in the directory. Overall, the return has been welcomed, because dashboard notifications are one of the worst parts of the experience and get worse the more plugins you have. Continuing the shift toward “server-aware” collaboration, the **Core** team has published a guide for testing the three candidate sync engines, all in an experimental plugin called Gutenberg Sync Engines. *Yjs* is the closest to Google Docs, with live cursors and very fast updates, but it hides conflicts, because one of two simultaneous changes wins without warning, and it requires maintaining two implementations, in JavaScript and in PHP. *DE-RTC* is the most similar to the WordPress of old: it only syncs on save, by default every ten seconds, and sets genuine conflicts aside for someone to review. It isn’t real-time, but it’s cheap for modest hosts and lets plugins, scripts, or WP-CLI participate almost like a person would. *Intent-log* sends descriptions of what each person did, such as “split this block,” which gives the server context and a readable history, though it processes one update per entry at a time and its merge logic isn’t mature yet. The underlying debate hits close to hosting. There are five possible transports, from simple polling, which works anywhere, to WebSockets, which requires a separate process, and the guide warns that most shared hosts don’t support long-lived connections, so the typical site will end up on polling, whichever engine wins. A new **bbPress** release, again a security and maintenance one, so update again if you run forums. It hardens validation of topic and reply passwords and makes shortcodes stay as literal text when they appear in normal WordPress content loops. The functional addition is a site-wide forum status setting with three modes: open, closed, and frozen; existing sites stay open unless changed. The rest is maintenance, mostly in the BuddyPress integration: profile actions, group topic routes, activity visibility, and group forum access. Compatibility with third-party theme package subscription links is also restored, moderation forms are preserved after a validation error, and fixes cover notifications, converters, widgets, profiles, theme and reply administration, and restricted content visibility. And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org. Thanks for listening, and until the next episode!