I've been trying to use You.com's built-in translation feature to navigate support documentation and community forums for several non-English SaaS tools. The results are actively unhelpful and are creating more confusion than they solve.
The translation output isn't just stilted; it fundamentally changes technical terms and instructions, often reversing their meaning. I've seen specific cases where German forum posts about API error codes were translated into nonsensical English phrases that bore no relation to the original technical context. This isn't a minor fluency issue—it's a critical failure for a tool positioning itself as a research assistant.
When users rely on this feature for technical support, they are being fed incorrect information. This damages both the user's ability to solve problems and the reputation of the communities whose content is being distorted.
Has anyone else run into this with other languages? More importantly, has You.com acknowledged this as a known issue with their translation layer? I've found no setting to disable it selectively when browsing foreign-language sites, which seems like a basic necessity until the quality is addressed.
—AF
—AF
You've precisely identified the core problem: it's not about fluency, it's about domain-specific terminology. Machine translation models trained on general corpora fail catastrophically when faced with technical jargon, API codes, or locale-specific error strings.
I've conducted my own unscientific benchmark using Japanese AWS documentation. The translation consistently substituted generic terms for service names like "Amazon S3," rendering the instructions useless. For instance, a phrase about "S3 バケットポリシー" was translated to "S3 bucket measure," which is actively misleading.
The lack of a disable toggle is the most concerning architectural oversight. Forcing a broken, non-deterministic transformation layer onto source material without user consent violates a basic principle of tooling: do not silently corrupt the data. I'd be curious if anyone has performed a systematic comparison of the output against Google Translate or DeepL for technical texts. My suspicion is they're using an under-tuned open-source model without a proper glossary layer.
Trust but verify.
The terminology point is spot on, but I'm less convinced by the "lack of a disable toggle" being an architectural oversight. It's a product team decision, and a boneheaded one at that. They've welded a flashy, half-baked feature directly into the view layer because it's a checkbox for a marketing slide.
The real architectural failure is pretending machine translation is a solved problem you can just bolt on. They didn't build a "translation feature," they built a "mandatory distortion layer." A proper implementation would at least have a terminology passthrough, a simple regex to skip things in ALL_CAPS or wrapped in backticks.
I've seen this pattern before: a team gets pressured to ship an AI feature, grabs the cheapest available model API, and calls it a day. The cost of not doing glossary mapping isn't just bad UX, it's eroding trust in the core product. It's infrastructure as a liability.
monoliths are not evil
The point about a mandatory distortion layer hits home. It reminds me of a similar issue with early cloud dashboard translations, where region codes got translated. Absolute chaos.
Do you think the pressure to use the "cheapest available model API" is the main driver here, or is it more about not having a clear owner for technical accuracy? In a B2B context, who typically pushes back on this - engineering or product?
Yeah, I've seen this happen with Japanese Kubernetes docs. A phrase about "Ingress リソース" came out as "entrance resource," which made no sense. It's not just German.
Has anyone found a workaround, like a browser extension that can block the translation layer? Or is the only option to avoid using you.com for non-English sources?
learning every day
Oh, that's a great question about who pushes back. In my experience, it's often the product team that's pushing to ship features for a release cycle, and engineering gets stuck trying to make it work with the given constraints. But shouldn't QA or someone with localization expertise have a say?
I've seen cheap APIs chosen because they're fast to integrate, not because they're accurate. That's a product decision, right? But engineering should be flagging the risks. It feels like a shared failure when no one owns the technical accuracy of the output.