Un banner de consentimiento que estaba bien en este sitio y mal en el paquete

Encontré un error en mi propio paquete compartido mientras arreglaba otro sitio, y resultó que ya había traído el mismo error hasta acá sin darme cuenta.

La versión corta: mientras agregaba portugués a vdaluz.com, estaba extendiendo el texto del componente PrivacyExplainer en @vdaluz/astro-opt-in-analytics, el paquete que renderiza el banner de consentimiento y el texto de la página de privacidad en todos mis sitios de Astro. Antes de eso, en el paquete solo existían las claves default y es. Agregar pt me llevó a revisar cada sitio que dependía de él, y este apareció: tiene una ruta /pt/privacy en vivo y renderiza el mismo banner de consentimiento en cada página pt a través de su layout, pero seguía fijado en v0.5.0.

Por qué nada parecía roto

El código propio de este sitio ya estaba correcto. Su configuración de analítica tenía texto en pt definido desde hacía meses, “Pode contar” para aceptar, “Não, obrigado” para rechazar. Nunca se usó, porque resolveLocalized() recae en .default (inglés) cada vez que una clave de idioma no existe en lo que se le pase, y es el paquete, no la configuración de este sitio, el que decide cuáles claves de idioma son válidas.

Entonces los visitantes en pt veían un aviso de consentimiento en inglés y una página de privacidad en inglés. Sin errores, sin advertencia de cadena faltante, nada que se viera mal desde dentro de este repositorio. Solo el idioma equivocado renderizándose en silencio, que es el mismo tipo de cosa que sigo encontrando en los límites entre paquetes.

La corrección, y las dos lecturas falsas durante la verificación

La corrección en sí fue una línea: subir la versión fijada del tarball de v0.5.0 a v0.5.1, npm install, reconstruir. La verificación tomó más tiempo que la corrección, a propósito, porque “idioma equivocado en silencio” es exactamente el tipo de error que una compilación limpia y un astro check exitoso no detectan.

Busqué con grep las cadenas reales en portugués dentro del HTML compilado, y después usé un navegador real en la página de inicio y la de privacidad en pt para verlo directamente. El primer intento no mostró nada, porque el perfil del navegador ya tenía una decisión de consentimiento guardada en localStorage de pruebas anteriores en este sitio, hechas semanas atrás, así que el banner estaba oculto por diseño. Al hacer clic en “Preferências de análise” en el pie de página se volvió a abrir, y ahí estaba: “Posso contar sua visita?” con ambos botones en portugués.

Después caí en la misma trampa otra vez después del despliegue. La primera solicitud en vivo que hice llegó a una compilación que había empezado antes de que existiera el commit, así que todavía servía las cadenas viejas en inglés. Tuve que comparar la marca de tiempo del despliegue contra la del commit antes de confiar en la verificación de “ya está en vivo,” un hábito que vale la pena tener, ya que un entorno de verificación que engaña es más común que una corrección que realmente falla.

Lección

Este error solo podía encontrarse mirando dos proyectos a la vez. Nada en las pruebas o verificaciones propias de este sitio detectaría jamás una clave de idioma faltante en un paquete de nivel superior, porque desde el punto de vista de este repositorio la configuración siempre era correcta. El error vivía enteramente en el espacio entre lo que este sitio configuraba y lo que el paquete realmente soportaba.

Los componentes compartidos entre repositorios son cómodos hasta el día en que hay que recordar que pueden desincronizarse de sí mismos.