We follow the simple rule: anything that could cost money or destroy data when mistranslated is translated by humans, the rest goes through machine translation and gets a quick once-over.

TradingFXVPS is targeted at a crowd of traders and brokers from all over the world, and in most of the text on our site, we don't have much to translate at all. Most of the text on the dashboard, status messages and troubleshooting articles (such as how to connect to RDP) will have been translated by machine, and then looked over by a bilingual member of staff for about 10 minutes to ensure that all is well with terms and images. The articles are largely step-by-step, with lots of images, so it is largely 'filler' type text.

For our Billing pages, refund information, as well as the buttons that perform "destructive actions" or affect money/other critical data in other words - irrevocable actions (e.g. Reinstall OS, Cancel service, Rebuild server - yes, we had to learn this the hard way too), full human translation is required.

Tagging strings with what they do, rather than where they are used (e.g. in a help article) results in a very simple rule: only "red" strings (i.e. those that are going to cause destructive, financial or legal action) are translated by humans. This usually accounts for less than 5% of the strings in a given release, and thus results in a very small human translation queue. Content that has been translated by machines is released the same day as the rest of the release, and the translator only gets to polish the strings that actually matter.

Legal text is the one place where light-touch machine translation quietly breaks things, and I learned exactly where that line sits at Wonder.Legal, working across multilingual legal document templates.

The decision rule isn't about content type, it's about whether a mistranslation changes what a document legally does. Structural language, headers, instructions, the interface chrome around a form, can go through machine translation with a light pass, because getting a label slightly off costs you clarity, not enforceability. The operative clauses inside an actual legal document are different — a mistranslated term there can quietly change an obligation, a deadline, or which jurisdiction's rules apply, and nobody catches that on a light pass because it still reads fine, it's just wrong.

So the rule is translate the shell fast, and route anything carrying legal or contractual weight through a full human pass no matter how clean the machine translation reads. Fluency isn't the risk. A sentence can be grammatically perfect and still swap "may" for "shall" in a way that changes the whole document.

Support articles sit closer to the shell end of that line, and interface copy usually does too, but the moment either one starts explaining a legal right or a deadline, it crosses over. That's the actual test: not the document type, what happens if this specific sentence turns out to be wrong.

The decision to use machine translation with light post-editing or fully human translation is determined by how near the content is to either transactional risk or user frustration. While dealing with global customers in various languages, the best way to formulate decisions is to categorize content as mostly low-friction operational actions and high-volume information inquiries.
Standard support articles that describe frequent low-risk operations like changing a profile setting or navigating a dashboard represent the ideal candidates for machine translation and some post-editing. Such content is designed specifically to be scalable and easy to understand. Nonetheless, user interface components, emergency notifications, and documents concerning sensitive issues such as billing or data security must be translated through professional localization from the start.
One of the good decision-making rules is to check for the negative effect of mistranslation: if errors can result in quick escalation or lockout of an account, then the decision is to use human translation only. For example, when updating support information on telecom or financial services, standard parts of content are run through machine translation with a fast review by a native speaker to check for comprehensibility. However, any text connected with money transfers and contract cancellations must be translated professional. Hence, it is possible to avoid errors in such sensitive activities as automating crucial devices.

My rule is to let agentic translation handle repetitive, low-risk interface text with a light human review, and to require full human translation for sensitive or customer-facing support articles. When we implemented agentic AI to reduce friction, we deliberately gave it more autonomy on low-risk tasks while keeping tighter human review for sensitive decisions. That allowed routine labels, error messages, and draft content to move quickly without delaying releases, while complex support content received full human localization. We structured the system to be reversible and explicit about where human judgment must apply, which preserved quality and speed.

My rule is simple: what happens if the user misunderstands this sentence?

For routine navigation labels or support instructions where a mistake is easy to spot and reverse, machine translation with light review can be appropriate. Anything involving payments, permissions, security, data deletion, or account recovery needs a qualified human translator working with the product context. Short text doesn't automatically mean low risk.

Take "Remove account." Does that mean disconnecting it from a device or permanently deleting the account and its data? A translator needs to know before choosing the wording. If the source is ambiguous, we should fix it before translating it into ten languages.

At LanguageCheck.ai, where I'm CMO, our focus is helping teams assess translation quality and identify issues that deserve attention. I'd combine that assessment with the consequences of getting the content wrong. An automated check can flag a potential meaning error or inconsistent term, but it cannot decide how much risk a business should accept.

A practical example would be a release containing an updated settings menu and a new account-deletion flow. I'd route familiar, approved menu terminology through machine translation with light review, while sending the deletion flow—including its confirmation messages and linked support article—to a human translator with screenshots and a clear explanation of the behaviour.

Those two routes can run in parallel, with the sensitive content identified before translation starts. That gives the consequential wording proper attention without making every routine string wait for the same level of review.

The principle is to allocate review by the impact of an error, rather than by word count or how fluent the translation sounds.

I use one simple rule: prioritize full human translation for content that targets users actively evaluating products, and allow machine translation with light review for general informational content. For example, our comparison posts like "Remote vs. Remotify" and "Xolo Go vs. Remotify" draw readers who are making a decision, so we assign them to human translators to preserve nuance and trust. Less decision-focused support articles and FAQ pages go through machine translation followed by a quick native-speaker review to catch major issues. This keeps high-stakes content accurate while allowing the bulk of content to move through the release pipeline quickly.

The rule I'd defend is to sort strings by what a wrong reading costs the user. Buttons, menu labels, empty states and most help-center how-tos go through machine translation with a quick review pass. A misread there makes someone tap twice and move on.

Anything carrying uncertainty or safety wording goes to a human translator. In a photo-analysis app, that means the result screen and the cleaning guidance. An AI answer says "possible" or "looks consistent with" for a reason. Machine translation tends to flatten that into something that sounds certain, and people trust a confident sentence more than the product should ask them to. The same goes for steps about protective gear and ventilation. A softened verb there is a real problem.

What keeps this from slowing a release is that the sorting happens once, at the string level. The developer tags each string when writing it, so nothing waits in a queue for a decision. The human translator only sees the small tagged set, plus a glossary and screenshots so they aren't guessing at context. Everything else ships on the fast path the same day.

That's how I'd set it up for a small team. It's a judgment call I can defend, not a measured result.

I decide by risk and length: short, low-risk interface strings and brief support snippets go through machine translation with a light native review. Longer support articles, marketing proof points, and any legal or medical content require full human translation and localization. One practical rule I follow is to use quick MT for short text and DeepL for longer sentences, then route only flagged or high-risk passages to human translators. Keeping key languages downloaded and tested ahead of time lets native reviewers validate drafts quickly and preserves release timelines.

Most companies treat that as a binary choice, when it's actually about signal. If a string has zero user-facing consequences if it's wrong, auto-translate and spot-check. If it shapes how someone understands what your product does or how to fix their own problem, it needs human eyes first.

We had a Pageloot support article about UTM parameters that went through machine translation for four languages. The auto-translate version said something like "track your users across the internet" which technically wasn't wrong but missed the actual job. The human version said "see which campaign or link drove each scan" which is what our customers actually care about. That one difference meant fewer support tickets in those languages because people understood the feature without needing to ask.

The decision rule that stuck: if it's in a help article, error message, or onboarding flow, assume someone's stuck and trying to fix it themselves. That goes to a human. If it's a billing receipt line item or a button label that's just a noun, machine translation plus a spot-check saves days. The person paying you is patient with a slightly awkward string. The person who can't get their QR codes working is not.

We started flagging strings by context, not by length. A 200-character help section beats a 20-character button label for translation investment, even though it seems backward. Shipped faster because we stopped translating everything equally and started translating by consequence.

The rule I use is simple. If a string names a food or tells someone how sure the app is, a human writes it. Everything else goes through machine translation and gets a quick read.

Buttons and most support how-tos are safe for the machine, because a wrong word there is obvious and gets fixed fast. Food and meal names fail quietly. A model can see "once" and read it as the number eleven, when in Chile it's an evening meal. Desayuno, almuerzo, merienda and once shift by country. A translated US app gets them slightly wrong, and nobody files a bug about it.

The other human-only bucket is anything describing an estimate. A calorie figure from a photo is an estimate, and the wording around it has to say so plainly. Machine translation tends to smooth a hedge into a confident statement, and that costs you trust.

This doesn't slow a release because the routing happens when the string is written. Each string gets a tag then, food or caveat versus plain interface text. The human pass covers a small slice of the strings, so reviewers stop rereading button labels and spend their time on the lines that can actually mislead someone.

The split I use is not "important vs unimportant", it is "read vs watched". Interface strings, settings labels and help articles are read at the reader's own pace, so machine translation plus a light native review is enough: a slightly stiff sentence costs a second of confusion, not a sale. Anything watched or timed, like video, voiceover or on-screen text, gets a native reviewer who checks it in context by playing the actual video, because the failures there are timing and tone, and nobody catches those in a spreadsheet. And anything that makes a claim (pricing, guarantees, what the product can do) goes to a human translator regardless of format, because a mistranslated claim is the same legal exposure in every market.

The rule of thumb that keeps releases moving: if a wrong word would only slow someone down, machine-translate it and ship. If it would mislead them or break the cut, a human signs off first.