De opdracht die de verkeerde zesentwintig talen wiste

Ik gaf de automatisering van mijn eigen site opdracht om de blog terug te brengen tot vier talen. Twee dagen later ontdekte ik dat diezelfde opdracht stilzwijgend ook zesentwintig talen van de homepage had gewist, zonder dat ik het merkte en zonder dat ook maar één bezoeker er iets van zei.

TL;DR

• Eén opdracht, bedoeld voor de blogsectie, werd toegepast op de hele site.
• 26 van de 30 talen verdwenen van de homepage, de cv-pagina en alle navigatieteksten.
• Niets crashte, niets gaf een 404, dus niemand merkte er twee dagen lang iets van.
• De oplossing kwam uit de git-geschiedenis, niet uit mijn herinnering aan hoe de site er ooit uitzag.
• De echte les: benoem, voordat een geautomatiseerde wijziging draait, precies welke bestanden ze raakt, en lees die lijst voordat er iets wordt verwijderd.

Waarom ik in de eerste plaats minder talen wilde

Mijn site was in een paar maanden tijd uitgegroeid tot dertig talen: homepage, cv-pagina en een blog die ik bijna om de paar dagen bijwerk. Ik schreef al eerder over hoe gevaarlijk dat kan worden: machinevertaling is vloeiend genoeg om overtuigend te lijken en fout genoeg om je voor gek te zetten, in een taal die je zelf niet kunt controleren. De homepage en de cv veranderen nauwelijks, dus dat risico kon ik daar wel dragen. De blog was een ander verhaal. Er verschijnen regelmatig nieuwe posts, en ik kan echt niet instaan voor de vertaalkwaliteit van een vers artikel in het Estisch, op de dag dat het gepubliceerd wordt.

Dus besloot ik het aantal talen waarin de blog vertaald wordt terug te brengen tot de vier die ik zelf nog kan controleren: Engels, Russisch, Duits, Tsjechisch. Al het andere blijft van de blog af tot ik een betere manier heb om het te verifiëren. Dat deel van het plan klopte. Wat misging, was hoe ik het formuleerde.

Eén zin, de verkeerde scope

Ik gaf één instructie: houd de blog op vier talen. Kort en specifiek, dacht ik. Wat er werkelijk gebeurde, raakte drie dingen tegelijk. De blogmappen zelf werden inderdaad correct teruggebracht tot de vier talen die ik wilde. Maar de instructie herschreef ook de hoofdlijst van talen van de hele site, het configuratiebestand dat bepaalt welke talen überhaupt bestaan, en verwijderde de homepage-content en navigatieteksten voor de overige zesentwintig.

Het probleem is dat “de blog” en “de talenlijst van de hele site” in hetzelfde configuratiebestand zitten. Niets in dat bestand maakt onderscheid tussen de talen die de blog ondersteunt en de talen die de site ondersteunt. Haal een taal uit die lijst, en elke sectie die eruit leest, homepage incluis, verliest hem in één klap. Mijn instructie noemde één sectie. De wijziging die daadwerkelijk draaide, had de scope van alles.

Dit is wat het gevaarlijk maakte, en niet slechts fout: er ging niets luidruchtig stuk. Geen foutmelding, geen 404, geen mislukte build. De site stopte gewoon stilzwijgend met het genereren van homepage- en cv-pagina’s voor zesentwintig talen, en de taalkiezer bood ze niet langer aan. Een bezoeker die de site altijd in het Portugees las, kwam nu geruisloos op de Engelse versie terecht. Verdwenen-door-verwijdering ziet er precies zo uit als nooit-heeft-bestaan, en geen van beide geeft een foutmelding.

Het duurde twee dagen voor ik het opmerkte, en dan nog per toeval, halverwege een compleet andere reparatie, toen een “Blog”-link in de navigatie ergens vreemds naartoe wees voor een taal waarvan ik dacht dat die nog gewoon live was. Die ene bungelende link was de enige zichtbare draad naar het hele probleem.

Wat de diff werkelijk liet zien

De eerlijke fout hier is niet de scope-vergissing zelf. Het is dat ik nooit heb gecontroleerd welke bestanden de wijziging daadwerkelijk zou raken, voordat ik hem liet draaien. Ik las een omschrijving van één zin over wat de wijziging zou moeten doen, en nam aan dat die ook beschreef wat er gebeurde. Dat klopte niet.

Het herstel begon met één vraag: wat is er veranderd, en waar. Ik vergeleek de live site met de laatste commit van vóór de “blog inperken”-instructie, en het antwoord was meteen duidelijk: de hoofdconfiguratie voor talen, de contentmap van de homepage en zesentwintig taalspecifieke stringbestanden, geen daarvan ook maar in de buurt van de blogmap. Git had elk van die bestanden nog precies zoals ze waren. Er was niets echt kwijt, alleen overschreven bij het deployen.

Ik herstelde de homepage, de cv en de navigatieteksten voor alle dertig talen uit die geschiedenis, en liet de blogmap precies zo ingeperkt als ik wilde: vier talen, met opzet. Eén los eindje bleef over. De “Blog”-link in de navigatie wees, voor een herstelde taal, nog naar een blogeditie in die taal die niet meer bestond. Vier posts opnieuw vertalen naar zesentwintig extra talen, alleen om die ene link te vullen, was de moeite niet waard, dus liet ik de template die link in plaats daarvan doorsturen naar de Engelse blog, en zo bleef het staan.

Wat ik de volgende keer anders zou controleren

Voordat ik nu een geautomatiseerde wijziging op een live site met meerdere secties laat draaien, stel ik hardop één extra vraag: benoem precies welke bestanden dit gaat raken, niet welke functie het geacht wordt op te lossen. Is het antwoord vaag, dan is dat het signaal om te stoppen en te controleren, niet om het gewoon te laten draaien en te kijken wat er gebeurt. En voordat er iets wordt verwijderd, wil ik eerst de daadwerkelijke bestandslijst voor me hebben, niet een samenvatting van één zin over wat de instructie geacht werd te betekenen. Een scope-woord in een instructie, “de blog”, “dit team”, “alleen de frontend”, is niet automatisch hetzelfde als de scope van de wijziging die die instructie in gang zet, en die twee komen alleen overeen als iemand daadwerkelijk heeft gecontroleerd dat ze overeenkomen: precies de vraag die ik nu aan jou terugstel. Wat is de kleinste, meest zelfverzekerd afgebakende instructie die je onlangs hebt gegeven, die nooit is gecontroleerd tegen wat hij daadwerkelijk raakte?