The Instruction That Deleted the Wrong Twenty-Six Languages

I told my own site’s automation to shrink the blog down to four languages. Two days later I found out it had quietly wiped twenty-six languages off the homepage too, and neither I nor a single visitor had noticed.

TL;DR

• One instruction aimed at the blog section got applied to the whole site instead.
• 26 of 30 languages disappeared from the homepage, the CV page, and every navigation string.
• Nothing crashed and nothing 404’d, so nobody noticed for two days.
• The fix came from git history, not from memory of what the site used to look like.
• The real lesson: before an automated change runs, name the exact files it touches, then read that list before anything gets deleted.

Why I wanted fewer languages in the first place

My site had grown to thirty languages over a few months: homepage, CV page, and a blog I update almost every few days. I’d already written before about how dangerous that gets: machine translation is fluent enough to look fine and wrong enough to embarrass you, in a language you personally can’t check. The homepage and CV barely change, so I could live with that risk there. The blog was a different story. New posts go out often, and I genuinely cannot vouch for the translation quality of a fresh article in Estonian on the same day it publishes.

So I decided to shrink the set of languages the blog gets translated into, down to the four I actually trust myself to sanity-check: English, Russian, German, Czech. Everything else stays off the blog until I have a better way to verify it. That part of the plan was sound. What went wrong was how I asked for it.

One sentence, the wrong scope

I gave a single instruction: keep the blog to four languages. Short, specific, or so I thought. What actually ran touched three different things at once. It correctly trimmed the blog’s own content folders down to the four I wanted. It also rewrote the site’s master language list, the config file that says which languages exist at all, and it deleted the homepage content and navigation strings for the other twenty-six.

The problem is that “the blog” and “the whole site’s list of languages” live in the same config file. Nothing in that file distinguishes which languages the blog supports from which languages the site supports. Remove a language from that list and every section that reads from it, homepage included, loses it in one shot. My instruction named a section. The change that actually ran had the scope of everything.

Here’s the part that made it dangerous rather than merely wrong: nothing broke loudly. No error, no 404, no build failure. The site just quietly stopped generating homepage and CV pages for twenty-six languages, and the language switcher stopped offering them. A visitor who used to read the site in Portuguese would just silently land on English instead. Missing-because-deleted looks exactly like never-existed-in-the-first-place, and neither one throws an error.

Two days passed before I caught it, and only by accident, mid-way through an unrelated fix, when a “Blog” link in the navigation pointed somewhere odd for one of the languages I thought was still live. That single dangling link was the only visible thread back to the whole problem.

What the diff actually showed

The honest failure here isn’t the scope mistake itself. It’s that I never checked the list of files the change was actually going to touch before I let it run. I read a one-line description of what it was supposed to do and assumed that described what it did. It didn’t.

Fixing it started with one question: what changed, and where. I diffed the live site against the last commit from before the “trim the blog” instruction, and the answer was immediate and unambiguous: the master language config, the homepage content folder, and twenty-six per-language string files, none of them anywhere near the blog directory. Git had every one of those files exactly as they were. Nothing was actually lost, only deployed over.

I restored the homepage, CV, and navigation strings for all thirty languages from that history, and left the blog folder exactly as trimmed as I wanted it: four languages, on purpose. One loose end remained. The “Blog” nav link, for a restored language, used to point at a blog edition in that language that no longer exists. Duplicating four posts into twenty-six more languages just to fill that one link wasn’t worth it, so I set the template to redirect it to the English blog instead, and left it there.

What I’d check differently next time

Before I let any automated change touch a live, multi-section site now, I ask one extra question out loud: name the exact files this is going to touch, not the feature it’s supposed to fix. If the answer is vague, that’s the signal to stop and check, not to run it and see. And before anything gets deleted, I want the actual file list in front of me first, not a one-line summary of what the instruction was supposed to mean. A scope word in an instruction, “the blog,” “this team,” “just the frontend,” is not automatically the same as the scope of the change that instruction triggers, and the two only match if something actually checked that they do: which is exactly the question I’d ask you back. What’s the smallest, most confidently scoped instruction you’ve given lately that never got checked against what it actually touched?