A Instrução Que Apagou os Vinte e Seis Idiomas Errados

Disse à automação do meu próprio site para reduzir o blog a quatro idiomas. Dois dias depois, descobri que também tinha apagado silenciosamente vinte e seis idiomas da página inicial, e nem eu nem um único visitante deu por isso.

TL;DR

• Uma instrução dirigida à secção do blog acabou aplicada ao site inteiro.
• 26 dos 30 idiomas desapareceram da página inicial, da página de CV e de todas as strings de navegação.
• Nada falhou e nada deu erro 404, por isso ninguém reparou durante dois dias.
• A correção veio do histórico do git, não da memória de como o site costumava ser.
• A lição real: antes de uma alteração automatizada correr, nomeia os ficheiros exatos que ela vai tocar, e lê essa lista antes de apagar seja o que for.

Porque é que eu queria menos idiomas, para começar

O meu site tinha crescido para trinta idiomas em poucos meses: página inicial, página de CV e um blog que atualizo quase de poucos em poucos dias. Já tinha escrito antes sobre o quão perigoso isso pode ser: a tradução automática é fluente o suficiente para parecer correta e errada o suficiente para te deixar em apuros, numa língua que tu próprio não consegues verificar. A página inicial e o CV quase não mudam, por isso conseguia viver com esse risco aí. O blog era outra história. Publico artigos novos com frequência, e sinceramente não consigo garantir a qualidade da tradução de um artigo recém-publicado em estónio no mesmo dia em que sai.

Por isso, decidi reduzir o conjunto de idiomas para os quais o blog é traduzido, aos quatro em que realmente confio para conseguir verificar: inglês, russo, alemão, checo. Tudo o resto fica fora do blog até eu ter uma forma melhor de o verificar. Essa parte do plano estava certa. O que correu mal foi a forma como pedi.

Uma frase, o âmbito errado

Dei uma única instrução: manter o blog em quatro idiomas. Curta, específica, ou pelo menos foi o que pensei. O que realmente correu mexeu em três coisas diferentes ao mesmo tempo. Reduziu corretamente as pastas de conteúdo próprias do blog aos quatro idiomas que eu queria. Mas também reescreveu a lista mestra de idiomas do site, o ficheiro de configuração que diz quais os idiomas que existem, e apagou o conteúdo da página inicial e as strings de navegação dos outros vinte e seis.

O problema é que «o blog» e «a lista de idiomas de todo o site» vivem no mesmo ficheiro de configuração. Nada nesse ficheiro distingue quais os idiomas suportados pelo blog dos idiomas suportados pelo site. Remove um idioma dessa lista e todas as secções que a leem, incluindo a página inicial, perdem-no de uma só vez. A minha instrução nomeava uma secção. A alteração que realmente correu tinha o âmbito de tudo.

Eis a parte que tornou isto perigoso e não apenas errado: nada falhou de forma barulhenta. Nenhum erro, nenhum 404, nenhuma falha de build. O site simplesmente deixou de gerar, em silêncio, as páginas iniciais e de CV para vinte e seis idiomas, e o seletor de idioma deixou de os oferecer. Um visitante que costumava ler o site em português passava simplesmente a cair em inglês, sem qualquer aviso. Faltar porque foi apagado parece exatamente igual a nunca ter existido, e nenhum dos dois casos dá erro.

Passaram-se dois dias antes de eu dar por isso, e só por acaso, a meio de uma correção sem relação nenhuma, quando um link de «Blog» na navegação apontava para um sítio estranho num dos idiomas que eu pensava que ainda estava ativo. Esse único link solto foi o único fio visível que levava de volta a todo o problema.

O que o diff realmente mostrou

A falha honesta aqui não é o erro de âmbito em si. É o facto de nunca ter verificado a lista de ficheiros que a alteração ia realmente tocar antes de a deixar correr. Li uma descrição de uma linha do que era suposto fazer e assumi que isso descrevia o que fez. Não descrevia.

Corrigir isto começou com uma pergunta: o que mudou, e onde. Comparei o site em produção com o último commit anterior à instrução de «reduzir o blog», e a resposta foi imediata e inequívoca: a configuração mestra de idiomas, a pasta de conteúdo da página inicial e vinte e seis ficheiros de strings por idioma, nenhum deles perto do diretório do blog. O git tinha cada um desses ficheiros exatamente como estavam. Na realidade, nada se tinha perdido, só tinha sido sobreposto no deploy.

Restaurei a página inicial, o CV e as strings de navegação para os trinta idiomas a partir desse histórico, e deixei a pasta do blog exatamente tão reduzida como eu queria: quatro idiomas, de propósito. Ficou uma ponta solta. O link de navegação «Blog», num idioma restaurado, costumava apontar para uma edição do blog nesse idioma que já não existe. Duplicar quatro artigos em mais vinte e seis idiomas só para preencher esse link não valia a pena, por isso configurei o template para o redirecionar para o blog em inglês, e deixei assim.

O que verificaria de outra forma da próxima vez

Antes de deixar qualquer alteração automatizada tocar num site real com várias secções, faço agora uma pergunta extra em voz alta: nomeia os ficheiros exatos que isto vai tocar, não a funcionalidade que é suposto corrigir. Se a resposta for vaga, esse é o sinal para parar e verificar, não para correr e ver o que acontece. E antes de se apagar seja o que for, quero ter a lista real de ficheiros à minha frente, não um resumo de uma linha do que a instrução era suposta significar. Uma palavra de âmbito numa instrução, «o blog», «esta equipa», «só o frontend», não é automaticamente igual ao âmbito real da alteração que essa instrução dispara, e as duas coisas só coincidem se alguém realmente verificar isso: que é exatamente a pergunta que te devolvo a ti. Qual foi a instrução mais pequena e com o âmbito mais confiante que deste ultimamente e que nunca foi verificada em relação ao que realmente tocou?