Decirle a un lector en español por qué la página está en inglés
El soporte de español de este sitio tiene un fallback integrado: si una página o un post del blog todavía no tiene una traducción real, Astro sirve en silencio la versión en inglés en la URL en español en vez de devolver un 404. Esa es la opción correcta por defecto, un enlace roto es peor que contenido en inglés, pero tiene un problema de experiencia de usuario que nadie había señalado hasta que una revisión de diseño lo detectó: es silencioso. Un lector en español hace clic en el selector de idioma, cae en /es/blog/some-post, y recibe una página 100% en inglés sin ninguna explicación. Parece que el selector está roto, no que es un fallback deliberado.
El arreglo es una barra de aviso de una línea, pero encontrar una forma confiable de detectar “esta página es un fallback” llevó más excavación que la interfaz en sí. Acá hay dos situaciones genuinamente distintas, y necesitan dos chequeos distintos.
La primera es una página como la página de marketing de Deep Cut Atlas, que no tiene ningún archivo de ruta en español, así que el fallback de ruteo de Astro renderiza el mismo componente en inglés tanto para /apps/deep-cut-atlas como para /es/apps/deep-cut-atlas. Ya sabía, por un gotcha de i18n anterior, que Astro.url.pathname miente en estas páginas renderizadas por fallback, reporta la ruta que hizo match, no lo que en realidad se pidió. Lo que no había confirmado hasta ahora: Astro.currentLocale NO miente de la misma forma. Hice curl a ambas URLs y comparé el atributo <html lang="..."> renderizado, y efectivamente, la URL en español reporta correctamente lang="es" aunque el contenido en sí nunca cambie. Ese único booleano, currentLocale === 'es', alcanza para decir “esta página entera es un fallback en inglés,” ya que el componente en sí no tiene ninguna noción de español para empezar.
La segunda situación es el blog, que sí tiene una ruta real /es/blog/[...slug].astro, solo que únicamente algunos posts tienen una traducción real al español. Acá currentLocale siempre es 'es' sin importar si este post en particular está traducido, así que es inútil como señal. La respuesta real ya estaba ahí, en los propios datos de la ruta: el getStaticPaths() de la ruta pasa la entrada de la colección cruda, sin normalizar, y para un post sin traducir el id de esa entrada todavía empieza literalmente con en/, aunque la esté renderizando la ruta en español. Revisar ese prefijo antes de que cualquiera de los helpers existentes lo recorte para armar la URL, y con eso se sabe exactamente cuáles posts son fallback sin agregar ni un solo campo nuevo en ningún lado.
La parte que casi me salté: después de conectar ambos chequeos, habría sido fácil confirmar que el aviso aparece en las páginas sin traducir y darlo por terminado. Esa es la mitad fácil. La mitad que en verdad atrapa una condición equivocada es confirmar que el aviso NO aparece donde sí existe una traducción real, hice curl a las seis páginas de fallback y a las seis páginas reales (los posts traducidos, la página de inicio en español, la página de privacidad en español) buscando el texto exacto del aviso y comparé los conteos. Seis unos, seis ceros. Esa asimetría es todo el sentido de la prueba.
Una cosa que miré y deliberadamente no hice: el hallazgo original también sugería quitar la etiqueta hreflang en español de las páginas de fallback, para evitar que los buscadores indexaran contenido duplicado en inglés bajo dos URLs. Rastreé lo que eso en verdad requeriría y no es de una sola línea, la página en inglés sigue anunciando una alternativa hreflang en español para cada post sin importar el estado de traducción, así que quitarla unilateralmente solo del lado del español no es recíproco, algo que la mayoría de las herramientas de SEO simplemente ignora. Y este sitio ya autocanonicaliza deliberadamente las páginas en español hacia su propia URL, así que quitar la alternativa mientras se mantiene esa autocanonicalización manda una señal mixta. El arreglo real ahí es apuntar la etiqueta canonical hacia la URL en inglés específicamente para las páginas de fallback, un cambio más considerado de lo que la sugerencia de una línea daba a entender. Lo dejé afuera en vez de publicar algo que parece un arreglo pero no cambia en realidad lo que se indexa.
Lecturas relacionadas
Traducir una página de marketing sin duplicarla
La página en español existía, tenía una URL, aparecía en hreflang, y cada palabra estaba en inglés. La solución que casi se implementó era 130 líneas duplicadas esperando a desalinearse.
La portada fue la única página que el i18n olvidó
El selector de idioma funcionaba perfecto. Solo que no había nada del otro lado: seis componentes de literales en inglés, un archivo de datos plano en inglés, y un servidor de desarrollo que mintió durante veinte minutos.
El párrafo que se saltó la traducción porque nunca preguntó
Un párrafo del pie de página estaba codificado en inglés junto a cadenas en español completamente traducidas, porque nunca estuvo en el archivo de cadenas i18n compartido.