A multilingual WordPress plugin has to keep your translations somewhere, and where it keeps them decides what you maintain later. SwiftLing keeps translations in its own database tables, keyed to the original page, so it does not create a copy of your page for each language. WPML and Polylang store each translation as a separate post. TranslatePress also uses its own tables. This post shows what that means, what I measured, and what it costs.
I tested the claims below on test sites, and I say where I did not.
Short answer
- SwiftLing: one page, many languages. The translated texts live in SwiftLing’s tables.
- WPML and Polylang: one post per language, linked together.
- TranslatePress: translated strings in its own tables, so it is closer to SwiftLing than to WPML on this point.
- The price of SwiftLing’s approach is a small cost on translated pages and the need to check each page builder, both explained below.
Where each plugin keeps a translation
| Plugin | Unit of translation | Where it is stored |
|---|---|---|
| WPML | A post per language | A row for every post in icl_translations, linked to its translations by a shared group ID (trid) (WPML’s own table documentation) |
| Polylang | A post per language | Separate posts, linked by a hidden taxonomy |
| TranslatePress | A string | Dictionary tables such as wp_trp_dictionary_* |
| SwiftLing | A text of the original page | Eight SwiftLing tables, for example wp_swiftling_strings |
I checked the storage of WPML 4.9.5, Polylang and TranslatePress 3.3.8 in test sites while building SwiftLing’s importers. Plugins change, so check the version you run.
What I measured on SwiftLing
On a test site I translated one page into Croatian and counted before and after:
| Before | After | |
|---|---|---|
| Published pages | 4 | 4 |
| Rows in the posts table (pages, posts, templates, attachments, revisions) | 77 | 77 |
Rows in wp_swiftling_strings | 70 | 103 |
The page was translated, and no page was added. To repeat it on your own site, run the first query before and after you translate a page:
SELECT COUNT(*) FROM wp_posts WHERE post_type IN ('page', 'post') AND post_status = 'publish';
SELECT COUNT(*) FROM wp_swiftling_strings;What this changes for you
- Editing the original. With a post per language, the translated posts keep the old text until someone updates each one. SwiftLing keeps the translation tied to the text it was made from, and the editor marks a text as changed since it was translated.
- One layout. A page builder layout exists once. A text without a translation shows in the original language, so a visitor never sees an empty block.
- Nothing extra to delete. There is no second post to redirect, hide or remove. Deleting the plugin keeps your translations, and Settings, General, Start over removes them.
- A copy when you want one. If a language needs another layout, SwiftLing can make a separate copy of that page for that language only.
None of this makes SwiftLing free of bugs. It removes one kind of problem, translated copies that drift from the original, and it has its own kinds.
What it costs
- Speed. SwiftLing looks up each text it translates. On my benchmark site (a shop with 1,000 products, with Redis), an original page took at most 5 ms longer than without SwiftLing, and a translated page 26 to 46 ms longer. This site, swiftling.pro, runs SwiftLing and scores grade A on GTmetrix (performance 88%, LCP 1.5 s, TBT 0 ms, CLS 0), but that measures the whole site, not SwiftLing alone. My benchmark is one machine and one theme, and the texts were copied, not really translated, so treat it as a rough size.
- Every page builder has to be checked. SwiftLing reads texts where WordPress hands them over, so a builder that prints its pages another way can hide texts. Brizy was one: it keeps what it prints as encoded data, and SwiftLing found no text in it until version 1.0.2. The builders I checked are on the compatibility page.
- Pro features of a builder may not be checked. For Brizy, I tested the free elements, not its Pro ones.
Which one should you choose?
If every language needs a different page, with its own layout, content and settings, plugins that make a post per language fit that well. If the pages are the same in every language and only the texts differ, keeping the translations apart from the pages is less to maintain. TranslatePress and SwiftLing both work this way, and the differences between them are in the details: which texts are found, and how addresses, SEO titles and page builders are handled. I tested that for SwiftLing, so try both on a copy of your site.
Moving from WPML or Polylang
SwiftLing Pro reads WPML, Polylang and TranslatePress data and brings the translations into SwiftLing. What carries over and what does not is in the import documentation. Try it on a copy of your site first.
Questions
Does SwiftLing create a copy of my pages for each language?
No. Translations are kept in SwiftLing’s own tables. You can still make a separate copy of one page for one language.
Does SwiftLing work with page builders?
It works with the block editor and with builders that keep their content in WordPress, such as Elementor, Beaver Builder, Breakdance, Brizy and Avada. See the compatibility page for what was checked.
Is SwiftLing really free?
Yes. SwiftLing is free on WordPress.org, with any number of languages. SwiftLing Pro adds DeepL and AI translation, a glossary and importers.
What happens to my translations if I delete SwiftLing?
They stay in the database. Settings, General, Start over removes them.
Last updated 29 October 2026. SwiftLing 1.0.3.