Translation Is Hard to Stop, but You Can Set Boundaries

Yohei Kano (aka Hey9Woz)

Table of Contents

Introduction

The translation button feels light. What happens behind it often is not.

When a page changes language with one tap, it is easy to imagine that everything happened neatly inside the device. Sometimes that is true. Sometimes it is not.

That gap matters.

This article is about a practical framing I keep coming back to:

translation is hard to fully control, so the safer move is to design the boundary well

TL;DR

  • Translation now behaves more like part of the environment than like an optional feature.
  • The biggest practical difference is whether text stays on-device or leaves the device.
  • If confidentiality matters, do not design around the assumption that browser translation is fully controllable.
  • Best-effort suppression is still useful, but it is not a guarantee.
  • "Prevent flowing out" is usually a better design goal than "perfectly stop translation."

Translation Is Not Just a Feature Anymore

Modern translation is less like a separate tool and more like ambient infrastructure.

People do not always open a dedicated translation site anymore. They:

  • translate inside the browser
  • paste into a translation tool
  • rely on operating-system level assistance

From a user perspective, that is convenient. From a web engineer's perspective, it creates a strange problem: translation can act on your interface even when you did not design for it.

That is why I do not think of translation as "just another feature." It is closer to an environment condition.

That difference matters. If something behaves like the environment, trying to control it perfectly from the app layer becomes difficult very quickly.

Cloud and On-Device Translation Change the Boundary

The most important distinction is not visual. It is architectural.

There are roughly two categories:

  • cloud translation: text leaves the device and gets processed elsewhere
  • on-device translation: translation stays inside the device

The practical question is simple:

how far does this text remain inside my own world?

If confidentiality is involved, that question should come early.

A lot of people do not instinctively feel that "translation" can also mean "sending." But in many cases, that is exactly the boundary you are crossing.

So when sensitive content is present, I think the safe default is:

if you are not sure, treat it as data that may leave the device

Decide the Boundary First

Because translation behaves like an environment, I do not think the first decision should be:

Can we control translation?

A better first decision is:

Is this content allowed to leave the device at all?

Once you ask that question, the design discussion becomes clearer.

Things worth checking include:

  • Does the text contain personal data or confidential information?
  • Who is using the screen: end users, internal staff, outside partners, or a shared device?
  • Do you know whether processing is cloud-based, on-device, or unclear?
  • Can you tolerate logs, retention, or secondary handling outside your product?
  • Can you separate "safe to translate" areas from "do not let this out" areas?
  • If the text leaks through screenshots, copy, or forwarding, is recovery impossible?

When in doubt, design as if the content may go outside. Boundaries should not depend on optimistic guesses.

Design for Not Letting It Flow Out

I do not think the realistic goal is "stop translation completely." That goal is brittle.

The better goal is:

make the safe path the natural path

In practice, that means two things:

  • use best-effort suppression where appropriate
  • shape the UI so sensitive content is less likely to be sent out in the first place

"Do not translate" is weaker than people want it to be. "Do not let sensitive content leave the safer path" is often more actionable.

A Minimal Translation Suppression Set

Best-effort suppression still matters. It is just not a guarantee.

For pages where you want broad suppression, a minimal set looks like this:

<html lang="ja" class="notranslate" translate="no">
<head>
  <meta name="google" content="notranslate" />
</head>

The practical rules I would follow are:

  • if you want page-level suppression, put it in the template rather than hoping individual components remember it
  • if only part of the UI is sensitive, isolate that block explicitly
  • do not rely on translate="no" alone
  • do not treat any suppression combination as a perfect stop

In other words, layer it, but stay realistic.

Smooth UI Often Hides the Boundary

This is not unique to translation.

Photo upload, social posting, AI analysis, and translation all share one trait: the smoother the UI becomes, the easier it is to forget that a boundary may have been crossed.

What users see is transformation. What may actually be happening is transmission.

That gap is where a lot of product risk quietly lives.

Translation Will Expand into Broader Transformation

Translation will not stay limited to text replacement.

Voice, subtitles, images, chat, and mixed interfaces will all continue to blend together. At the same time, on-device options will likely improve, which is genuinely helpful.

But even if the quality becomes more natural and the experience more seamless, the boundary question does not disappear.

If anything, it becomes easier to miss.

That is why I think the durable question is not:

Can we stop translation?

It is:

Where should the boundary be, and how do we design around it?

Summary

  • Translation is no longer just a feature. It often behaves like part of the environment.
  • The real practical difference is whether the text stays local or leaves the device.
  • If the boundary matters, decide that first instead of assuming the browser can be fully controlled.
  • Best-effort suppression is useful, but it is not a guarantee.
  • In many systems, "do not let it flow out" is a stronger design principle than "stop translation."