diff --git a/src/content/blog/technical/documentation-translations-fail-at-maintenance.mdx b/src/content/blog/technical/documentation-translations-fail-at-maintenance.mdx
new file mode 100644
index 000000000..766e65f42
--- /dev/null
+++ b/src/content/blog/technical/documentation-translations-fail-at-maintenance.mdx
@@ -0,0 +1,81 @@
+---
+title: 'Documentation Translations Fail at Maintenance, Not at Launch'
+subtitle: Published July 2026
+description: >-
+  Most teams treat documentation translation as a one-time project. The real problem is what happens after: source docs change, translated versions don't.
+date: '2026-07-23T00:00:00.000Z'
+author: Frances
+tag: Technical
+section: Use Cases
+hidden: false
+---
+import BlogNewsletterCTA from '@components/site/BlogNewsletterCTA.astro';
+import BlogRequestDemo from '@components/site/BlogRequestDemo.astro';
+
+A developer in Osaka opens your quickstart guide in Japanese. They follow the authentication steps. Step three returns an error. The parameter was renamed six weeks ago in a minor release. The English page was updated the day the release shipped. The Japanese page still shows the old name.
+
+Your translator did their job correctly. The translation was accurate when it was published. It became wrong when the product changed and nobody told the translation.
+
+This is the failure mode that teams discover through support tickets from international users, weeks or months after the drift started compounding.
+
+## The math of multilingual drift
+
+[Documentation drift](https://promptless.ai/blog/technical/documentation-drift-detection-problem) is already a significant problem in a single language. Postman's 2024 State of the API report found that 68% of developers cite outdated documentation as their top frustration when working with APIs. Research puts API specification conformance at around 25%.
+
+Every translated version of your docs multiplies that problem.
+
+When a product change makes your English quickstart inaccurate, you have one stale page. If you also maintain Japanese, German, and French versions, that same change creates four stale pages simultaneously. The English page usually gets updated quickly because someone catches it on their way through the codebase or via a support ticket in English. The translated pages stay broken until an international user files a bug or complains.
+
+The ratio gets worse as documentation grows. A team with 200 documentation pages and three translations is managing 600 translated pages alongside 200 English originals. If 15% of source pages drift per quarter (a conservative estimate), that's 30 English updates cascading into 90 translated pages needing updates. Most teams don't have a workflow that handles this automatically.
+
+[Documentation debt](https://promptless.ai/blog/technical/documentation-debt-accrues-where-your-team-cant-see-it) accrues in proportion to how hard it is to see. Stale English pages are at least visible to the team. Stale translated pages are largely invisible until a user reports them.
+
+## Why the standard workflow breaks down
+
+The typical documentation translation workflow: write in English, send to a translator, publish the translation, repeat when there's a new feature. The first round works. Maintenance breaks down.
+
+The problem is detection. Maintenance rounds require someone to notice that a source doc changed and flag which translated pages need updating. In practice, nobody has that job.
+
+Engineering teams assume it belongs to the documentation team. The documentation team assumes it belongs to whoever manages localization. The localization vendor only knows a translation is stale if someone tells them the source changed. The gap between "source doc updated" and "translated doc updated" averages weeks to months.
+
+This is not a translation speed problem. Professional translators turn around updates in days. The delay is entirely in the detection layer: nobody noticed the English page changed, so nobody told the translator.
+
+Manual audit workflows don't solve this. A quarterly review of translated content catches drift that has already happened, but doesn't prevent the next round of drift. Asking engineers to flag translated pages when they update source docs creates a dependency on memory and goodwill that breaks at the first rushed sprint.
+
+<BlogNewsletterCTA />
+
+## Where AI fits and where it doesn't
+
+AI-assisted translation has reduced the cost of initial translation significantly. Orchestrated AI workflows now cost roughly $0.002 per word, compared to $0.20 per word for traditional human translation. Teams that previously couldn't afford Japanese and German translations can now maintain them without significant budget strain.
+
+But cheaper initial translation doesn't fix maintenance. AI tools will [translate your updated English pages](https://promptless.ai/blog/technical/technical-writing-with-ai) quickly. They can't tell you which pages need translating because they don't know which source pages changed.
+
+The bottleneck has shifted. Translation cost is no longer the constraint. The constraint is knowing what to translate and when.
+
+## What actually keeps translations in sync
+
+Teams that maintain accurate multilingual documentation are solving a detection problem. They've connected translation maintenance to the same change signals that drive English documentation updates.
+
+When a developer updates an API endpoint, the documentation pages covering that endpoint need to surface for review in every language. When authentication changes, the quickstart guides need to surface in every language. This doesn't happen automatically in any standard translation workflow. It happens when teams monitor code changes and connect them to documentation coverage across all versions.
+
+The signal is always the same regardless of how many languages you support: a product change happened, and these specific pages now need review. The source of that signal is the same for your Spanish docs as for your English ones. Building a workflow that closes the loop between "source doc updated" and "translated page flagged for review" reduces the lag from months to days.
+
+### Stop auditing, start monitoring
+
+The default response to stale translated docs is an audit: find all translated pages, compare them to the source, flag differences, queue updates. Audits work once. They don't work as a maintenance strategy because they're snapshots, and drift is continuous.
+
+The more durable approach treats translation maintenance as a monitoring problem. Source changes surface translated pages for review automatically. A reviewer confirms which pages are affected. The translator receives an update scoped to the changed content, not a full re-translation request.
+
+This keeps the queue of stale translations from compounding into the hundreds and makes it possible to stay current without a dedicated localization team running parallel to your documentation team.
+
+## The international trust problem
+
+Stale documentation erodes developer trust in a pattern that's hard to reverse. Developers who hit enough broken pages stop trusting the docs and start pinging your team directly. This problem is more visible in international markets because the failure mode is unambiguous: a developer followed your Japanese quickstart and hit an error. They know something is wrong. They're not sure whether the translation is inaccurate or the product actually behaves differently.
+
+The support overhead compounds with scale. A single English documentation error generates a bounded number of support tickets. The same error replicated across four translations generates confusion from users who may have fewer options for getting help in English or from your support team's dominant language.
+
+For companies trying to grow developer adoption in international markets, translated documentation is supposed to close the gap between your product and developers who prefer to read in their own language. A translated quickstart that works is worth the investment. A translated quickstart that fails is worse than no translation because it makes a promise and then breaks it.
+
+The underlying fix is the same whether you're maintaining one language or ten: detect when source content changes and surface it for updates before a developer hits the stale page first. For translated documentation, getting that detection right means that AI translation tools can actually deliver on the cost reduction they promise. The translators have the capacity. The blocker is knowing what to send them.
+
+<BlogRequestDemo />