Keeping translations current when your site changes every week

Sites change more than they used to. Writing tools mean more pages, more often: a new landing page a week, product descriptions rewritten in an afternoon, a help centre that grows every time support answers the same question twice.

That's good for the site. It's bad for translations done as a project. A translation is a snapshot. The day it's done, it's right. Every edit to the original after that makes it a little more wrong, and nobody is watching.

How translations go stale

• The paragraph edit. Someone fixes a price, a date or a claim in English. The French page keeps the old one. The French visitor is now reading something that isn't true.
• The new page. A landing page goes live in English with no Spanish version. The Spanish site has a hole, and the Spanish visitor who follows the link lands in English.
• The renamed product. Marketing renames the product. Five languages still use the old name, because nobody went looking.
• The quiet drift. No single edit is worth a translation ticket, so nothing gets re-translated, and after a year the languages describe slightly different companies.

The usual fix is a schedule: re-translate everything every quarter. That buys you a quarter of stale pages and a project each time.

Translate the page, not the project

FluentC takes the project out of it. It translates pages as they're served, not as a batch.

With Domains, FluentC reads your pages from your site, so what it translates is what's there now, not a copy someone exported. A new English page has a Spanish address as soon as it exists, because the Spanish address is your site, translated. Translations are saved, so text that hasn't changed isn't translated again, and a one-line fix doesn't cost you the page.

With the WordPress plugin, the same happens inside WordPress: edit the original and the translated versions follow.

Either way, the price doesn't move when the site grows. It is flat per site, per language, with no limit on pages or text, so publishing a page a week doesn't start a meter. See pricing.

What you still do

• Read the lines that matter after a change. A new page gets a machine translation first. If it carries a claim, a price or a legal line, read it in the languages you sell in and fix anything in the dashboard. What to review first.
• Fix a renamed term once. In the dashboard, change the translation where it matters. On WordPress, keep the plugin's glossary current, so the new name is used the same way across the site.
• Mark what must not be translated. Legal text that is only valid in one language gets the skip comment, so it's left as it is while the rest of the page is translated.

A short checklist for a site that changes every week

1. Every language on its own address, served from the live site, not from an export.
2. New pages exist in every language the day they go live.
3. Edits to the original reach every language without a ticket.
4. The lines with consequences get a read in each language you sell in.
5. Terms that changed are fixed once, in one place.
6. The cost is known before the next page is published.

If your setup does the first three on its own, the other three are an hour a month. If it doesn't, they're the project you keep postponing.