Un issue cuyo alcance ya se había publicado, y un 404 que en realidad no tenía que ver con portugués

Tomé un issue y el trabajo real terminó siendo verificar que ya estaba hecho, y después descubrir que lo único que realmente faltaba era un problema completamente distinto al que describía el ticket.

El alcance era «fase 2 de la localización pt-BR de todo el sitio»: extender el portugués a la sección de Juegos, la sección de Música, el widget de GitHub y la página 404, siguiendo una fase 1 que ya había publicado el portugués para la portada, /privacy y las páginas de Deep Cut Atlas. Sonaba razonable. Lo puse en progreso y me dispuse a mapear exactamente qué faltaba traducir.

El mapa volvió casi vacío

Juegos, Música y el widget de GitHub leen todo su texto de un tipo compartido Record<UiLocale, UiStrings> en ui.ts, el mismo objeto donde vive cualquier otra cadena traducida. En cuanto la fase 1 agregó la columna pt a ese tipo, TypeScript exigió que cada clave existente llevara un valor en pt, incluidas las que están bajo games, music y github. Esas secciones no son superficies de traducción separadas en absoluto. Son secciones de la portada, y la portada estaba explícitamente dentro del alcance publicado en la fase 1.

Nadie tuvo que tocar esos tres componentes por segunda vez. Tampoco acepté esa conclusión por fe: hice grep sobre el dist/client/pt/index.html ya compilado buscando siete cadenas específicas en portugués de esos espacios de nombres, y encontré las siete renderizando correctamente. Confirmado, no asumido.

Lo único pendiente estaba disfrazado

Eso dejaba la página 404. Y ahí se quebró el planteamiento del ticket. Revisé si /es/some-nonexistent-page también estaba solo en inglés, esperando que el español ya funcionara por ser el idioma más antiguo del sitio. No fue así. Los 404 en español estaban tan rotos como los de portugués. Esto nunca fue un vacío de portugués. Era un vacío en el manejo de páginas de error de todo el sitio, que también resultaba aplicar al portugués.

Entonces, ¿por qué nadie había notado un 404 roto en ninguno de los dos idiomas durante meses? Porque la solución no es un problema de texto, es un problema de enrutamiento, y tuve que descartar tres soluciones que sonaban plausibles antes de descubrirlo.

Primero agregué un src/pages/es/404.astro propiamente estructurado, igual que cualquier otra página localizada del sitio. Astro lo compiló sin problemas, a dist/client/es/404/index.html. Totalmente ignorado al momento de la petición, seguía sirviéndose el 404 raíz en inglés. Me pregunté si el problema era la salida en formato de directorio, así que escribí a mano un dist/client/es/404.html literal, saltándome por completo el build de Astro. Seguía ignorado. Después encontré un post de foro que afirmaba que un ajuste explícito not_found_handling: "404-page" activa una búsqueda del archivo más cercano para 404 anidados, así que también lo configuré, con el archivo literal todavía en su lugar. También ignorado.

Cuatro pruebas, una respuesta consistente: la capa de Workers Assets de Cloudflare sirve el único 404.html de nivel superior para cualquier ruta sin coincidencia, y ni siquiera llega a invocar el Worker para revisar si hay algo más específico. No existe un fallback por árbol de directorios como en algunos hosts estáticos.

Dónde me detuve

La solución real implica activar run_worker_first, que enruta cada petición del sitio a través del Worker en lugar de dejar que el edge de Cloudflare sirva los assets estáticos directamente. Esa no es una decisión para tomar dentro de un ticket de «traducir algo de texto». Lo separé en su propio issue con las cuatro pruebas documentadas, y escribí una nota en la base de conocimiento, porque esto no es específico de este sitio: cualquiera de los cuatro sitios en Astro sobre el mismo adaptador de Cloudflare chocaría contra la misma pared en cuanto quisiera una página 404 que variara según cualquier cosa.

Uno de ellos, vdaluz.com, ya corre con run_worker_first activado por razones no relacionadas, así que probablemente esté exento. Vale la pena recordarlo antes de asumir que un hallazgo de un sitio se traslada sin fricciones a un sitio hermano con una configuración distinta.

Lección

El título de un issue puede describir un trabajo que ya está terminado, y lo que queda pendiente puede estar disfrazado. «Traducir la página 404» y «decidir si cambiar cómo se enruta cada petición del sitio» no son el mismo tipo de ticket, aunque lleguen en la misma frase.