Fighting for good translations of WordPress UI (core, plugins, themes, etc.) is more painful in 2026 than ever before.

The reason is AI.

But I need to be much more specific.

Machine translation is a type of AI-tooling that has been around for at least some 20 years to speed up human translation. These tools have improved immensely over the years, and today, with a good TM (Translation Memory), and a well-tuned MT (Machine Translator) you can often get almost perfect results.

The new trend now, though, is that a lot of developers instead of specialized MT tools, have started using commercial LLMs (like ChatGPT, Claude, and other) to bulk translate their plugins/themes into a lot of languages they personally don’t speak.

The main problem is that after spending a few minutes (and a large number of tokens), they expect the unpaid volunteer contributors of the Polyglots’ team to validate/fix/improve their translations, a task that takes substantially more effort, more than the Polyglots’ volunteers can handle. For most locale teams the backlog of pending strings grow with thousands of new strings every week. (Ref: https://translate.wordpress.org/stats/ )

Only a few locale teams manage to regularly clear their backlog. In most cases, the only way to achieve this is by spot-checking and then approve or reject the whole submission in bulk.

By the way “approving or rejecting in bulk” is one of the things we need to make much easier. Our current “bulk” commands only deal with one screenful of strings at a time.

Another problem is that the developers, obviously, want to make their shiny new machine translations available to the users and apply for the PTE role (Project Translator Editor – a bit like “translation committer”). The number of PTE requests has exploded. Today we get at least 10 times more PTE requests over a week than we used previously. In addition, they request PTE not for the one-two languages they speak, but for 10-20 locales.

Since the PTE role is supposed to be a quality assurance step, most locale teams want to make sure that the requester knows the target language well; and we get stuck.

So what are we doing?

The Polyglots team has started discussions around what can be done to improve the situation. Here are a few directions.

Help LLM users make better translations

Many locale teams have published style guides. We can adapt these for LLM ingestion:

• Write the style guide itself in English
• Use markdown syntax
• Optimize the instructions for use with LLM
• Make it easier to find these style guides

Creating a new machine translator role

This type machine translations isn’t going to disappear. Instead, we need to make room for it in our systems. We may create a new role, where a contributor is able to distribute translations, but they can’t approve/reject/edit already approved translations from other users.

Also, unverified machine translations should not be added to the translation memory, which allows easy reuse of previous translations from anywhere in the project.

To some extent, we already have similar functionality for a different role, CL-PTE (cross-locale project translation editors – a role used when a developer submits translations that have been checked by professional translators).

The role of WordPress Polyglots’ also changes

We’ve been building and coaching volunteer translators to make better translations.

Now we need to coach developers about using machine translations in a smart way and guide them more about internationalization (preparing their code in ways that allow for better translations).

Next steps

We’ve just started talking about these things. Last weekend we had a video meeting with Polyglots contributors from all between Japan and all over Europe.

That discussion continues.

I also intend to talk to plugin/theme developers, to get their view on these things.

PS

While I wrote this short text, we the team received another three PTE requests. I’m off to handle them.

A few weeks ago “Thirst”, the newest book by Jo Nesbø, was released in Swedish. (It will be realeased in English tomorrow.) I wanted to buy it and found that one of the best prices was offered by www.signon.se.

By the way, if it wasn’t for a direct link from pricerunner.se, I’d never found the book on their site, since their internal search logic is really bad. They state that you can search on title, author, publisher, etc., but in reality you can only search for any single one of these arguments. And you must get a 100% match. Try typing “Jo Nesbø” without Norwegian or Danish keyboard layout!

So I added the book to my order and went to check-out. First I would had to register. And this is were things went awkward. Obviously, the site uses https, so the communication between my browser and their server is encrypted. But what do they do with my data?

Firstly: The password I created for this website was e-mailed back to me! To me, this an obvious signal that their whole thinking around security is flawed. It’s quite possible that they store my password in clear in their database, which is insecure practice. Almost all current frameworks know to instead store hash values that are created using individual salt strings and cryptography, and never ever send e-mails with the password in clear. The industry practice is to only send one-time nonce-values upon request that then are used to allow password to be reset if lost or forgotten.

Secondly: The account was immediately activated without any verification of my e-mail address. With a simple script you could start stuffing their database with fake accounts and even have them automatically send out confirmation emails as spam, possibly with insulting passwords written in clear!

Next, I went to the beautiful check-out page, which proudly shows off a DIBS logo. Would I trust DIBS with my credit card details? Yes, they’re OK. But would I trust signon.se with my details? No, not really. So I had a quick look at the code behind the page. The form was programmed to deliver my credit card details to their own server. That helped me make my final decision.

End of story: I decided to pay about one euro more, but to a different vendor.

First of all, a big “Thank you” to those of you, who have contributed and continues to contribute in making WordPress available in various languages, including Swedish.

All translation of WordPress core, and most translations of plugins and themes are handled via the online platform GlotPress. Anyone is welcome to take part in this work. You just need to register a free account at www.wordpress.org, and then you may head over to https://translate.wordpress.org/ and start translating!

However, one important task for us, is to create and maintain a consistent user experience for a localized (i.e. translated) WordPress.

One important tool for this is the glossary, where we have collected useful comments on specific words and phrases and in many cases give the specific term we’ve chosen to use.
One example: The English word “shortcode” might be translated into Swedish in various ways, and we’ve simply chosen the word “kortkod” for this term.
You can check out the Swedish glossary here:
https://translate.wordpress.org/projects/wp/dev/sv/default/glossary

If you’ve been translating anything for WordPress core, then you may have seen translated terms and comments automatically show up in the translator view. In a future version of GlotPress we may expect these useful hints to show up during translations of any plugin or theme.

But in the meantime, I’d like to tell you about a very useful tool, which will “inject” translator hints in these other projects already today.
It’s “GlotDict” an add-on for Firefox and Google Chrome, developed by @Mte90, Daniele Scasciafratte from Italy. More information can be found at https://github.com/Mte90/GlotDict

If you want to help in translating WordPress into Swedish, then you’re more than welcome. And please join our special slack channel: #translations at https://wpsv.slack.com/ (You’ll need an invitation to Slack, which you can get from anyone, who’s already there.)