All to Lat — Latin Slugs by Transliteration for WordPress and WooCommerce

All to Lat makes every link on the site Latin. WordPress builds a slug from the title — and with a Ukrainian title, the address ends up carrying %d0%b0%d0%b1%d0%b2: in search results it looks spammy, it breaks when copied into a messenger or an email, and it tells the reader nothing. The plugin transliterates the title first, so the address reads upravlinnia-nerukhomistiu.

Nothing 404s after conversion

A renamed post is redirected by WordPress itself — via _wp_old_slug. A renamed category or tag is not redirected that way: the core simply has no such mechanism for taxonomy terms, and a category that used to answer to the old address starts returning 404, along with every link pointing to it. This 301 is sent by the plugin itself, from its own log, and only for a request that has already found nothing — a live handler page is never touched.

The plugin’s interface is in Ukrainian: the translation ships in the build, nothing extra to install.

What to know before turning it on

Turning it on only affects slugs created from this moment on. Existing addresses only change once you run the bulk conversion yourself — it warns you, shows a preview, and leaves a log you can roll back.

What the plugin doesn’t do

It doesn’t touch drafts. WordPress deliberately keeps a draft’s slug empty and fills it in from the title on publish — if the address were set now, it would freeze on the unfinished title, with nowhere to roll back to: there simply is no previous value. That’s why bulk conversion only works on items that already have an address.

Why a shop needs this

WordPress takes the slug from the title, and if the title is in Cyrillic, the slug gets Cyrillic in it. In the browser such an address looks fine, but the moment it’s copied anywhere, it turns into %D0%BA%D1%83%D0%BF%D0%B8%D1%82%D0%B8, a full screen wide.

This hits in three places at once: a link in a messenger looks like spam, analytics show unreadable URLs, and some external services (aggregators, marketplaces, some mail clients) simply cut such addresses short.

How it works, step by step

1. The plugin is enabled and from then on silently intercepts the moment WordPress builds a slug.

2. The title is transliterated using the Ukrainian table — specifically Ukrainian, not “Russian for everyone”: і, ї, є, ґ are handled correctly, and щ becomes shch, as in the passport standard.

3. A new post, product, category or tag gets a Latin slug straight away. Nothing needs clicking.

4. For what’s already published, there’s bulk conversion — in one pass over the whole catalogue.

5. Old Cyrillic addresses get a 301, so search rankings and external links aren’t lost.

What the admin gets

The settings screen is minimal: which post types to affect, and a bulk conversion button. The plugin doesn’t add any widgets, blocks or anything to the front end.

The slug stays an ordinary WordPress field — it can be edited by hand, and the plugin respects that instead of overwriting it on the next save.

Technical requirements

WordPress 6.2 or newer, PHP 7.4 or newer. WooCommerce isn’t required: the plugin works on a plain blog too, and with Woo it also covers products, categories and attributes.

Under the hood

Transliteration hooks into WordPress’s standard slug filter, not into JavaScript in the editor form. This matters: the slug comes out Latin even when the post is created by an import, the REST API, or another plugin — exactly where a JS-based solution wouldn’t work at all.

301 redirects are stored separately and don’t depend on the theme. Disable the plugin and old addresses stop redirecting, but nothing breaks.

How to install

1. Upload the archive under “Plugins → Add New → Upload Plugin” and activate it.

2. Check on one new post that the slug came out Latin.

3. If the catalogue is already in Cyrillic, back up the database and run the bulk conversion.

4. Confirm old addresses return a 301 to the new ones.

Version history

1.1.0 — the preview only searched the first rows and, on a site with fresh Latin content, said “nothing to change” while the counter nearby showed hundreds; the converter was writing slugs to drafts with no way to roll them back; the 301 for renamed categories used to die as soon as you disabled transliteration for new links — it now has its own switch; if a category and a tag shared one address, both old addresses used to point to just one of them — now the request path decides; “Roll back” used to erase the log entry even when the slug couldn’t be restored, taking the redirect down with it; a long run used to silently stop at the batch ceiling — it now says where it stopped and continues from there. Counters are now calculated by the database rather than PHP (the settings page no longer lags on a large catalogue), and admin script and styles were moved into files. Minimum WordPress version is now 6.2.

1.0.0 — first release.