Publicar en dos idiomas sin que el inglés se pudra

Hay un patrón que se repite en casi todos los sitios bilingües pequeños: al principio se traduce todo, a los tres meses se traduce lo importante, y al año hay una versión en inglés con cuatro páginas de 2023 y un menú que lleva a rutas que no existen.

No es falta de ganas. Es que traducir es trabajo opcional, y el trabajo opcional pierde siempre contra el que no lo es.

Lo que hicimos

Que no sea opcional. El build falla si una entrada existe en un idioma y no en el otro:

✗ Paridad de traducciones: 1 problema(s)

  · blog/dos-idiomas: falta la versión en "en" (existe en: es).
    Crea src/content/blog/en/<slug>.md con el mismo id.

No hay forma de desplegar medio traducido. Se publica en los dos idiomas o no se publica.

El emparejamiento no es por nombre de archivo

Este es el detalle que hace que la idea funcione en la práctica. Si emparejas traducciones por el nombre del archivo, te obligas a que el slug sea idéntico en los dos idiomas — y entonces o el español lleva slugs en inglés, o el inglés lleva slugs en español. Las dos opciones son malas para quien lee y para la indexación.

Cada entrada lleva un id estable, y el slug es libre:

src/content/blog/es/dos-idiomas.mdx      → id: dos-idiomas
src/content/blog/en/keeping-english.mdx  → id: dos-idiomas

Ambas comparten id, así que el selector de idioma sabe llevarte a la misma página en lugar de a la portada, y hreflang se genera solo.

Lo que cuesta

Un artículo cuesta el doble de escritura. Eso es real y no lo vamos a maquillar: hemos publicado menos por esta regla.

Lo aceptamos porque el fallo contrario es peor. Un sitio con la mitad en inglés a medias no parece bilingüe, parece abandonado — y esa impresión se contagia a todo lo demás, incluidas las aplicaciones que sí funcionan.

Si algún día nos frena de verdad, la salida es marcar una entrada como monolingüe explícitamente. Lo que no vamos a hacer es relajar la comprobación en silencio, que es como empiezan todos los sitios que acaban así.