La instrucción que borró los veintiséis idiomas equivocados

Le dije a la automatización de mi propio sitio que redujera el blog a cuatro idiomas. Dos días después descubrí que también había borrado en silencio veintiséis idiomas de la página de inicio, y ni yo ni un solo visitante se había dado cuenta.

TL;DR

• Una instrucción dirigida a la sección del blog se aplicó a todo el sitio.
• 26 de los 30 idiomas desaparecieron de la página de inicio, la página de CV y todas las cadenas de navegación.
• Nada se rompió ni dio error 404, así que nadie se dio cuenta durante dos días.
• La solución vino del historial de git, no de la memoria de cómo se veía antes el sitio.
• La lección real: antes de que un cambio automatizado se ejecute, hay que nombrar los archivos exactos que va a tocar, y leer esa lista antes de que se borre nada.

Por qué quería menos idiomas, para empezar

Mi sitio había crecido hasta treinta idiomas en pocos meses: la página de inicio, la página de CV y un blog que actualizo casi cada pocos días. Ya había escrito antes sobre lo peligroso que es esto: la traducción automática es lo bastante fluida como para parecer correcta y lo bastante imprecisa como para dejarte en ridículo, en un idioma que tú mismo no puedes revisar. La página de inicio y el CV casi no cambian, así que podía asumir ese riesgo ahí. El blog era otra historia. Publico artículos nuevos con frecuencia, y sinceramente no puedo garantizar la calidad de la traducción de un artículo recién salido, el mismo día que se publica, en estonio.

Así que decidí reducir el conjunto de idiomas a los que se traduce el blog, a los cuatro que sí me atrevo a revisar yo mismo: inglés, ruso, alemán, checo. Todo lo demás se queda fuera del blog hasta que tenga una forma mejor de verificarlo. Esa parte del plan era sólida. Lo que salió mal fue cómo lo pedí.

Una frase, el alcance equivocado

Di una sola instrucción: mantener el blog en cuatro idiomas. Corta, específica, o eso creía. Lo que realmente se ejecutó tocó tres cosas distintas a la vez. Recortó correctamente las carpetas de contenido propias del blog a los cuatro idiomas que quería. Pero también reescribió la lista maestra de idiomas del sitio, el archivo de configuración que dice qué idiomas existen en absoluto, y borró el contenido de la página de inicio y las cadenas de navegación de los otros veintiséis.

El problema es que «el blog» y «la lista de idiomas de todo el sitio» viven en el mismo archivo de configuración. Nada en ese archivo distingue qué idiomas soporta el blog de qué idiomas soporta el sitio. Quitar un idioma de esa lista hace que cualquier sección que la lea, la página de inicio incluida, lo pierda de un solo golpe. Mi instrucción nombraba una sección. El cambio que realmente se ejecutó tenía el alcance de todo el sitio.

Aquí está la parte que lo volvió peligroso y no solo equivocado: nada falló de forma ruidosa. Ningún error, ningún 404, ningún fallo de compilación. El sitio simplemente dejó de generar en silencio las páginas de inicio y de CV para veintiséis idiomas, y el selector de idioma dejó de ofrecerlos. Un visitante que antes leía el sitio en portugués simplemente aterrizaba en inglés sin ningún aviso. Que algo falte porque se borró se ve exactamente igual a que nunca haya existido, y ninguno de los dos casos lanza un error.

Pasaron dos días antes de que lo detectara, y solo por casualidad, a mitad de una corrección sin relación, cuando un enlace de «Blog» en la navegación llevaba a un sitio raro para uno de los idiomas que yo creía que seguía activo. Ese único enlace roto fue el único hilo visible que llevaba de vuelta a todo el problema.

Lo que el diff realmente mostró

El verdadero fallo aquí no es el error de alcance en sí. Es que nunca revisé la lista de archivos que el cambio iba a tocar antes de dejarlo correr. Leí una descripción de una línea de lo que se suponía que debía hacer y asumí que eso describía lo que hizo. No fue así.

Arreglarlo empezó con una sola pregunta: qué cambió, y dónde. Comparé el sitio en producción contra el último commit anterior a la instrucción de «recortar el blog», y la respuesta fue inmediata e inequívoca: la configuración maestra de idiomas, la carpeta de contenido de la página de inicio y veintiséis archivos de cadenas por idioma, ninguno de ellos cerca del directorio del blog. Git tenía cada uno de esos archivos exactamente como estaban. No se había perdido nada en realidad, solo se había sobrescrito en el despliegue.

Restauré la página de inicio, el CV y las cadenas de navegación para los treinta idiomas a partir de ese historial, y dejé la carpeta del blog exactamente tan recortada como quería: cuatro idiomas, a propósito. Quedó un cabo suelto. El enlace de navegación «Blog», para un idioma restaurado, solía apuntar a una edición del blog en ese idioma que ya no existe. Duplicar cuatro artículos en veintiséis idiomas más solo para llenar ese enlace no valía la pena, así que configuré la plantilla para redirigirlo al blog en inglés, y lo dejé así.

Qué revisaría de otra forma la próxima vez

Antes de dejar que cualquier cambio automatizado toque un sitio real y con varias secciones, ahora hago una pregunta extra en voz alta: nombra los archivos exactos que esto va a tocar, no la función que se supone que va a arreglar. Si la respuesta es vaga, esa es la señal para detenerse y revisar, no para ejecutarlo y ver qué pasa. Y antes de que se borre nada, quiero tener delante la lista real de archivos, no un resumen de una línea de lo que se suponía que significaba la instrucción. Una palabra de alcance en una instrucción, «el blog», «este equipo», «solo el frontend», no equivale automáticamente al alcance real del cambio que esa instrucción dispara, y las dos cosas solo coinciden si alguien de verdad lo comprobó: que es exactamente la pregunta que te devuelvo a ti. ¿Cuál es la instrucción más pequeña y con el alcance más claro que has dado últimamente y que nunca se comprobó contra lo que realmente tocó?