Instruktionen, der slettede de forkerte seksogtyve sprog

Jeg gav min egen sides automatisering besked på at skære bloggen ned til fire sprog. To dage senere fandt jeg ud af, at den i samme ombæring stille og roligt havde slettet seksogtyve sprog fra forsiden, uden at hverken jeg selv eller en eneste besøgende havde bemærket det.

TL;DR

• En enkelt instruktion, der var rettet mod blog-sektionen, endte med at blive anvendt på hele sitet.
• 26 ud af 30 sprog forsvandt fra forsiden, CV-siden og samtlige navigationstekster.
• Intet gik ned, og intet gav 404, så ingen opdagede det i to dage.
• Løsningen kom fra git-historikken, ikke fra min hukommelse om, hvordan sitet plejede at se ud.
• Den egentlige lære: før en automatiseret ændring køres, skal man navngive præcis de filer, den rører ved, og læse den liste igennem, før noget bliver slettet.

Hvorfor jeg ville have færre sprog i første omgang

Mit site var på få måneder vokset til tredive sprog: forside, CV-side og en blog, jeg opdaterer næsten hver anden dag. Jeg har allerede skrevet om, hvor farligt det kan blive: maskinoversættelse er flydende nok til at se rigtig ud og forkert nok til at gøre dig til grin, på et sprog du selv ikke kan tjekke. Forsiden og CV’et ændrer sig sjældent, så den risiko kunne jeg leve med der. Bloggen var en anden sag. Nye indlæg kommer ofte, og jeg kan ærligt talt ikke indestå for oversættelseskvaliteten af en helt ny artikel på estisk samme dag, den udgives.

Så jeg besluttede at skære antallet af sprog, bloggen bliver oversat til, ned til de fire, jeg rent faktisk kan stå inde for at tjekke selv: engelsk, russisk, tysk, tjekkisk. Alt andet holdes væk fra bloggen, indtil jeg har en bedre måde at verificere det på. Den del af planen var der ikke noget galt med. Det, der gik galt, var måden jeg bad om det på.

Én sætning, det forkerte omfang

Jeg gav én enkelt instruktion: hold bloggen til fire sprog. Kort og præcist, troede jeg i hvert fald. Det, der rent faktisk blev kørt, rørte ved tre forskellige ting på én gang. Det trimmede korrekt bloggens egne indholdsmapper ned til de fire, jeg ville have. Men det omskrev også sitets overordnede sprogliste, konfigurationsfilen der bestemmer, hvilke sprog der overhovedet findes, og det slettede forsidens indhold og navigationstekster for de resterende seksogtyve.

Problemet er, at »bloggen« og »hele sitets liste over sprog« bor i den samme konfigurationsfil. Intet i den fil skelner mellem, hvilke sprog bloggen understøtter, og hvilke sprog sitet understøtter. Fjern et sprog fra den liste, og enhver sektion, der læser fra den, forsiden inklusive, mister det på ét hug. Min instruktion navngav en sektion. Den ændring, der rent faktisk blev kørt, havde omfanget af det hele.

Her er den del, der gjorde det farligt frem for bare forkert: intet gik i stykker med brag. Ingen fejl, ingen 404, ingen build-fejl. Sitet stoppede bare stille med at generere forside- og CV-sider på seksogtyve sprog, og sprogvælgeren holdt op med at tilbyde dem. En besøgende, der plejede at læse sitet på portugisisk, landede nu bare lydløst på engelsk i stedet. Manglende-fordi-slettet ser præcis ud som aldrig-har-eksisteret, og ingen af delene giver en fejlmelding.

Der gik to dage, før jeg opdagede det, og kun ved et tilfælde, midt i en helt anden rettelse, da et »Blog«-link i navigationen pegede et underligt sted hen for et af de sprog, jeg troede stadig var i live. Det ene løse link var den eneste synlige tråd tilbage til hele problemet.

Hvad diffen faktisk viste

Den ærlige fejl her er ikke selve omfangsfejlen. Det er, at jeg aldrig tjekkede listen over filer, ændringen rent faktisk ville røre ved, før jeg lod den køre. Jeg læste en enkelt linjes beskrivelse af, hvad den skulle gøre, og gik ud fra, at den beskrev, hvad den gjorde. Det gjorde den ikke.

Rettelsen startede med ét spørgsmål: hvad ændrede sig, og hvor. Jeg diffede det live site mod det seneste commit fra før »trim bloggen«-instruktionen, og svaret var øjeblikkeligt og entydigt: den overordnede sprogkonfiguration, forsidens indholdsmappe og seksogtyve sprogspecifikke tekstfiler, ingen af dem i nærheden af blog-mappen. Git havde hver eneste af de filer præcis, som de havde været. Intet var faktisk gået tabt, det var bare blevet overskrevet ved deployment.

Jeg genskabte forsiden, CV’et og navigationsteksterne for alle tredive sprog fra den historik og lod blog-mappen stå præcis så beskåret, som jeg ville have den: fire sprog, med vilje. Én løs ende stod tilbage. »Blog«-linket i navigationen pegede for et genskabt sprog på en blogudgave på det sprog, som ikke længere findes. At duplikere fire indlæg ud til seksogtyve sprog mere, bare for at udfylde det ene link, var det ikke værd, så jeg satte skabelonen til i stedet at omdirigere det til den engelske blog, og der blev det.

Hvad jeg ville tjekke anderledes næste gang

Før jeg nu lader en automatiseret ændring røre ved et live site med flere sektioner, stiller jeg ét ekstra spørgsmål højt: navngiv præcis de filer, det her kommer til at røre ved, ikke den funktion, det skal rette. Er svaret vagt, er det signalet til at stoppe og tjekke, ikke til at køre det og se. Og før noget bliver slettet, vil jeg have den faktiske filliste foran mig først, ikke et resumé på én linje af, hvad instruktionen antageligt betød. Et omfangsord i en instruktion, »bloggen«, »dette team«, »kun frontenden«, er ikke automatisk det samme som omfanget af den ændring, instruktionen udløser, og de to stemmer kun overens, hvis nogen rent faktisk har tjekket det. Hvilket er præcis det spørgsmål, jeg vil stille tilbage til dig: hvad er den mindste, mest selvsikkert afgrænsede instruktion, du selv har givet for nylig, som aldrig blev tjekket op mod, hvad den rent faktisk rørte ved?