Multilingüe Primero
La mayoría de los productos CMS tratan "soporta múltiples idiomas" como un add-on que instalas después. Chinaski fue construido al revés: el idioma es una parte estructural del data model, de las URLs, de la interfaz de admin, y de cada página que el builder genera. Esta página recorre lo que "first-class" significa en la práctica, y lo que no necesitará parchearse después.
El idioma vive en el data model
Cada content type, páginas, posts, bloques, documentos, categorías, elementos de navegación, formularios, lleva su propio campo de idioma. Las traducciones son filas separadas enlazadas entre sí, no copias escondidas. Donde los layouts visuales se comparten entre idiomas, los contenidos de bloques por idioma viven en una tabla dedicada de traducciones, así un hero stack, por ejemplo, puede tener distinta redacción por idioma mientras comparte estructura.
La interfaz de admin habla el idioma del usuario
La UI de admin misma viene con traducciones integradas, y cada usuario puede elegir su propio idioma de interfaz de admin, hace default al default del site pero hace override por cuenta (esto incluye a la gente que solo alguna vez aprueba traducciones). Cuando los autores escriben contenido, el selector de idioma en cada formulario de contenido es la propia lista de idiomas configurada del site, nada inventado, nada mal escrito; la lista viene del mismo setting que impulsa las URLs públicas.
Los idiomas de derecha a izquierda vienen integrados
Árabe, hebreo, farsi, urdu, pashto, kurdo, sindhi, ídish y divehi se renderizan con dir="rtl" fijado en cada página generada (y con lang fijado correctamente al idioma de cada página en cada template de theme). El RTL no es un plugin ni un retoque de theme, está en el builder.
Output language-aware en todas partes
- Árboles de output por idioma. En modo de URL path o subdominio, cada idioma construye su propio árbol bajo su propio prefix/subdominio de idioma, con URLs canónicas por idioma correctas (subdominios por idioma incluidos), alternates de hreflang, entradas de sitemap, y paths de home de navegación.
- Labels de homepage y cookie notices por idioma. El título del índice del blog y el texto/labels del cookie-banner tienen todos settings por idioma, una sola fuente de config para el set de idiomas editorial de un site entero.
- Simplificación monolingüe. Un site de un solo idioma nunca recibe URLs con segmento de idioma; el modo se deriva automáticamente así los sites monolingües se quedan planos.
Tooling editorial multilingüe, no solo aware
- La cobertura de traducción se calcula por página y post y se muestra mientras editas: qué idiomas configurados tienen este contenido y cuáles no.
- Los templates de workflow de traducción te permiten definir idioma fuente, targets y content types una vez y reutilizarlos a través del site.
- El auto-create en un clic: un endpoint de la API (y también del admin) calcula los idiomas target faltantes del contenido y crea borradores traducidos en lote, auditado como todo lo demás.
- El tooling asistido por AI viaja por los mismos rieles: el MCP server integrado expone herramientas de traducir-y-auditar (traducir contenido, encontrar piezas sin traducción, encontrar gaps de contenido como meta descriptions faltantes por idioma), así el mantenimiento multilingüe también es scripteable.
El comportamiento de las páginas públicas es language-native
- Los search indexes se construyen por idioma, buscar contenido "es" busca en español.
- Las páginas estáticas mismas se sientan bajo URLs por idioma con tags canónicos por idioma.
- Los feeds RSS y los archivos de categoría se generan por idioma, así el feed de cada idioma es un feed real, no un feed etiquetado superficialmente.
- La publicación programada usa una zona horaria del site de forma consistente, así un post en español y uno en inglés publicados "a las 9:00" realmente aparecen cuando quieres que aparezcan.
Lo que cuesta "first-class"
Nada se esconde, pero la postura multilingüe sí significa que la complejidad del modelo vive en el data model (los slugs difieren por idioma; la translation key empareja equivalentes; overrides locales de URL por idioma). La regla práctica: decide tus idiomas antes del lanzamiento (ellos impulsan el modo de URL), y trata una traducción como hermana completa de la página fuente en lugar de una variante. Cuando sigues esos caminos, los buscadores reciben señales correctas y los visitantes reciben experiencias completas en cada idioma que el site declara.