LynBro Plugins
/ Translate
LynBro Plugins
/ Translate
Weglot charges €2,990 a year for the right to export translations you paid to have made. WPML forbids your own API key and sells credits instead. This plugin does neither, and the reason is simple arithmetic: we are not in the chain of money, so there is nothing for us to meter.
Free forever, with no paid tier planned. Translation runs from your server on your own key, so there is nothing for us to charge for.
to leave. Everything the plugin knows — languages, links, strings, and every remembered sentence — exports as one file, on the only tier there is.
Every translation lives in your own database. Export all of it — the languages, which post is a translation of which, the site strings, and every remembered sentence with its machine-or-human mark — as one file, at any time. One review of a hosted competitor puts the alternative plainly: after leaving, “I have had to manually edit 10 000 urls from the robots and sitemap files. In this time the website went from the top 3 keywords to NOT in the top 100.”
The request goes from your server straight to the provider, on your key. We never see the text and never see the key, so automatic translation costs us nothing — which is exactly why it is free here, with no credits, no word count and no quota. The plugin will also tell you what a run will cost before you start it. Nobody else in this category does that, and it is not because it is hard.
Correct a translation by hand, then change the original, then translate again: your sentence is still there. Each translated sentence is remembered against the sentence it came from, marked as machine or human, and a machine cannot replace a human. Changing an original marks its translations as behind — it does not touch a word of them. The market leader ships an erratum admitting it does the opposite.
No "Pro" tier, no nag screens. The features other plugins paywall are here from day one.
Hand a language model a page of HTML and it comes back with a block delimiter dropped, a CSS class renamed and %1$s turned into %1$er. So the page is taken apart first, only the runs of visible text are sent, and the structure is rebuilt around the answers. Block delimiters, shortcodes, attributes, and the contents of script, style, pre and code never leave your server.
Placeholders, inline formatting and the names that must not be translated are compared against the original. Anything that fails is kept in the source language, and the edit screen says which line and why. A page half in Danish is a page you can fix; a page with a broken shortcode is a support ticket.
“Read more” on eighty pages is one request, not eighty — across posts, not just within one. The second language costs noticeably less than the first, and re-running a page you have already done costs nothing at all.
Danish company sites address the reader as du. Left alone, a translation engine drifts to the dead-formal De, and the classic engines cannot be told otherwise: DeepL’s formality setting does not cover Danish at all, and Google, Azure and AWS have no such setting in any language. Here it is a setting, because a language model simply does as it is asked.
Language URLs with the default language staying at the root, so nothing you have already indexed changes. Reciprocal hreflang with x-default, generated from the translation links rather than assembled by hand, and a redirect from the wrong language’s address to the right one — which WordPress cannot do on its own.
The importer reads Polylang’s own tables — languages, which post is in which language, which posts are translations of each other, and the string translations — and shows you the counts before it writes anything. It changes nothing that belongs to Polylang, so both can run side by side while you satisfy yourself.
The plugin answers to pll_current_language(), pll_get_post(), pll__() and the rest, so the theme your agency wrote does not white-screen the moment you deactivate the old plugin. While Polylang is active, this stands aside entirely.
Elementor keeps the whole page in a custom field and leaves the post body with a copy nothing renders. A plugin that translates only the post body leaves an Elementor page in the original language with no sign of why. This one walks the Elementor tree.
One post per request, with a progress line and a Stop button, in your browser rather than on a schedule — because it spends your balance and that should not happen unattended. Stopping keeps what is done; starting again resumes where it stopped rather than paying twice.
What the alternatives cost, and what they do with the translations you paid for.
| Feature | Lynbro Translate | WPML | Weglot | Polylang |
|---|---|---|---|---|
| Translations stored in your own database | ✓ | ✓ | — | ✓ |
| Export all your translations, free | ✓ | ✓ | — | ✓ |
| Use your own API key | ✓ | — | — | ✓ |
| Automatic translation with no per-word charge | ✓ | — | — | — |
| Tells you the cost before the run | ✓ | — | — | — |
| Formality setting that covers Danish | ✓ | — | — | — |
| A hand edit survives re-translating | ✓ | — | — | ✓ |
| Translate everything in one action | ✓ | ✓ | ✓ | — |
| Translates Elementor page data | ✓ | ✓ | ✓ | — |
| Imports an existing Polylang setup | ✓ | ✓ | — | ✓ |
| No paid tier at all | ✓ | — | — | — |
The plugin charges nothing and has no paid tier. OpenAI charges you for the requests your own site makes on your own key, at their prices — a page of a few hundred words costs a fraction of a cent with a small model. We are not in between, which is the whole point.
Everything except machine translation works without one: languages, addresses, hreflang, the switcher, string translations, the Polylang import, and translating by hand. There is no account and nothing to sign up for.
No. Your sentence is stored against the sentence it translates, marked as yours, and read back on every later run instead of being asked for again. It follows the sentence too: move the paragraph or use it on another page, and your wording comes with it.
Its translations are marked as behind, so you can see which pages want a look. Nothing in them is changed or deleted.
Yes, and that is the intended way. The two use different taxonomy names, the importer only reads Polylang’s data, and the compatibility layer for pll_* stands aside while Polylang is active.
Not unless you say so. A new translation is created as a draft, and the setting that changes that has the reason printed next to it.
Yes — including the page data Elementor keeps in a custom field, which is the part other plugins miss. Polylang has no native Elementor support at all.
Every setting, language and remembered translation it created is removed. Your posts are not — including the translated ones, which by then are pages somebody has edited.