SMF·LINGUISE
Can a prompt replace Linguise?
Translation & localization — automatic website translation with translated URLs
Exhibit tracking slip
Verdict
What Linguise sells is not translation, it is the plumbing: translated pages living at real URLs with correct hreflang tags so search engines index them, all without touching the CMS. That plumbing is a translating reverse proxy with a cache and an override table — a genuine weekend for one site you control. The one-line install into any CMS, and the edge network serving it, are what you give up.
Exhibit A — The prompt
Received on31.07.2026Build a translating reverse proxy for one site you control.
Requests to /fr/... or /de/... fetch the corresponding page from the origin, translate the visible text, and serve the result. Everything else passes through untouched.
Parse with a real HTML parser and translate text nodes only. Never regex the markup: attributes, inline scripts and JSON-LD blocks get mangled, and the failure is invisible until a page stops rendering. Skip the contents of script, style, code and pre entirely, and skip any element carrying a translate="no" attribute.
Rewrite links in the translated page so internal URLs keep the language prefix and external ones do not. Emit hreflang link tags for every language including x-default, and a canonical pointing at the translated URL rather than the source. Getting hreflang wrong is the specific way this class of tool fails: the pages get indexed, then treated as duplicates, and the traffic never arrives.
Cache aggressively, keyed by the origin page's content hash and the target language, so an unchanged page is never re-translated. This is what keeps the translation bill bounded, and it is worth building before the translation itself.
An override table wins over everything: a per-URL, per-string map of corrected translations, applied after the machine pass. Product names, calls to action and legal wording all need it, and a tool without an override path gets abandoned the first time it mistranslates a price.
Out of scope: a visual on-page editor, client-side rendered applications, and multi-site support. Verify by checking a translated page in a search engine's URL inspector rather than by eye.Opening prefills the prompt — press enter to run it.
Exhibit B — What you lose
- B.1 installing on any CMS without touching the site's code
- B.2 edge caching close to the visitor rather than one server
- B.3 the visual editor for correcting translations on the page itself
- B.4 automatic handling of dynamic content and single-page applications
- B.5 somebody else absorbing a machine-translation bill that scales with traffic
Prior art
- LibreTranslateLicense: AGPL-3.0
Exhibit C — Why people still pay: install-anywhere and edge serving
Because it is a plug-in rather than an architecture change. A proxy in front of your site is a piece of infrastructure someone has to own, and for most site owners fifteen dollars is much cheaper than becoming that someone.
Questions
Can I move my Linguise translation edits across?
Linguise stores manual edits in its dashboard and exports them; they map onto the override table reasonably well. The mapping is per URL and per string, so a site restructure since the edits were made means redoing part of it.
Will the translated pages get indexed?
They can, if the hreflang tags, canonicals and sitemap entries are all correct and consistent. That is the hard part and the reason it is in the prompt three times — most homemade versions fail here rather than at translation.
What does it cost to run?
A small VPS at $5 to $10 a month plus the machine-translation calls. With caching by content hash, a stable site of a few hundred pages costs a few dollars once and almost nothing after.
What is the one thing that does not survive the rebuild?
Not owning a proxy. Everything a visitor sees now passes through code you wrote, so when it breaks, your site is down and not just your translations.
Related tools
Receipt