En este post, te guiaré a través del viaje real de implementación de jblueprint.dev usando un flujo de trabajo de Spec Driven Design con Speckit—un framework que te ayuda a moverte desde ideas de features hasta código funcional y validado de forma estructurada.

¿Por qué Spec Driven Design?

Antes de tocar una sola línea de código, dedicamos tiempo a:

1. Definir qué queríamos construir (especificación).
2. Aclarar ambigüedades con decisiones de producto (clarificación).
3. Planificar el enfoque técnico (planificación de implementación).
4. Dividir el trabajo en tareas ordenadas (generación de tareas).
5. Ejecutar con validación (implementación).

Este enfoque reduce el retrabajo, asegura claridad y crea un registro vivo de decisiones que puedes explicar más tarde. Perfecto para un blog donde quieres documentar tu razonamiento.

Contexto del Proyecto

• Proyecto: jblueprint.dev
• Stack: Jekyll
• Objetivo: Agregar soporte multilingüe (español e inglés)
• Plugin i18n: jekyll-polyglot

Reglas Fundamentales

1. Implementación solo en inglés: Todo el código y comentarios están en inglés para mantenibilidad.
2. Cumplimiento Jekyll-first: Sigue las convenciones oficiales de Jekyll y documentación.
3. Validación de build: Cada cambio que afecte el sitio requiere verificación local con bundle exec jekyll build.

El Flujo de Trabajo en 5 Pasos

Paso 0: Fundación

Detectamos que el repositorio ya tenía estructura Speckit (directorio .specify/) y creamos una constitución de proyecto que formalizó nuestros principios:

• Implementación solo en inglés
• Cumplimiento Jekyll-first en decisiones técnicas
• Validación de build para cambios que afecten la salida del sitio

Esta constitución guiaría cada decisión adelante.

Paso 1: Especificación y Clarificación

Usando speckit.specify, creamos la primera especificación de feature: “Add Multilingual Support (Spanish and English)”.

La especificación definió:

• Historias de usuario: Leer en idioma preferido, cambiar idioma sin perder contexto, mantener contenido bilingüe confiablemente.
• Requisitos funcionales: Estrategia de URLs, cambio de idioma, comportamiento de fallback, SEO.
• Criterios de éxito: 100% de páginas principales accesibles en ambos idiomas, 95% cambios de idioma exitosos, cero enlaces rotos.

Luego, usando speckit.clarify, resolvimos las 5 decisiones de producto más críticas:

1. Estrategia de URLs: Idioma por defecto sin prefijo (/...); español con prefijo (/es/...).
2. Prefijos de locale no soportados: Redirigir con HTTP 301 al equivalente de idioma por defecto.
3. Traducciones faltantes: Redirigir con HTTP 302 + mostrar mensaje de retroalimentación.
4. Persistencia de preferencia de idioma: Solo en sesión (se reinicia en nueva sesión del navegador).
5. Discoverabilidad SEO: Requerir etiquetas hreflang recíprocas y x-default en páginas bilingües.

Resultado: Una especificación completamente aclarada, lista para planificación técnica.

Paso 2: Planificación de Implementación

Usando speckit.plan, generamos artefactos de diseño:

• plan.md — Estrategia general y fases
• research.md — Análisis técnico profundo y detalles del plugin Polyglot
• data-model.md — Estructuras de datos de localización
• contracts/multilingual-routing-contract.md — Reglas detalladas de URL y redirección
• quickstart.md — Checklist de validación para desarrolladores

Todos los artefactos reforzaron comentarios en inglés y pensamiento Jekyll-first.

Resultado: Un blueprint técnico completo, testeable e implementable.

Paso 3: Generación de Tareas

Usando speckit.tasks, convertimos el plan en un backlog ordenado de 33 tareas accionables:

• Fase 1 (Setup): Instalar jekyll-polyglot, configurar Gemfile, crear registro de locales.
• Fase 2 (Fundacional): Configurar _config.yml, crear layouts e includes multilingües, conectar cambio de idioma y SEO.
• Fase 3 (Historia de Usuario 1): Crear contenido bilingüe (index, about, posts) y validar rutas.
• Fase 4 (Historia de Usuario 2): Implementar selector de idioma con fallback y retroalimentación.
• Fase 5 (Historia de Usuario 3): Documentar flujo de autoría bilingüe.
• Fase 6 (Polish): Validación final, procedimientos de rollback, verificaciones SEO.

Cada tarea tenía:

• Rutas de archivos claras (Jekyll-first)
• Dependencias marcadas
• Pistas de paralelización
• Criterios de prueba independientes

Resultado: Un plan de implementación ordenado y paralelizable.

Paso 4: Implementación

Usando speckit.implement, ejecutamos las 33 tareas:

Cambios clave:

• Agregamos jekyll-polyglot a Gemfile y ejecutamos bundle install
• Configuramos enrutamiento de locale multilingüe en _config.yml
• Creamos includes compartidos para selector de idioma, etiquetas SEO y retroalimentación de traducción
• Escribimos script de preferencia basado en sesión en assets/js/language-session.js
• Creamos contenido bilingüe: index.markdown, about.markdown y bienvenida en inglés y español
• Documentamos reglas de redirección, flujo de contenido y procedimientos de rollback

Validación:

• bundle exec jekyll build ejecutado exitosamente
• Sitio generado incluye rutas bilingües: /index.html, /es/index.html, etc.
• Etiquetas hreflang validadas en páginas bilingües
• Sin enlaces internos rotos

Resultado: Un blog Jekyll multilingüe completamente funcional y validado.

Paso 5: Rollout

Confirmamos todos los cambios con un commit limpio de rama de feature, listo para mergear.

Decisiones Clave Tomadas

Lo Que No Hicimos (Non-Goals)

• Agregar más de dos idiomas en este release
• Rediseñar el tema sin relación con soporte de idioma
• Reescribir todo el contenido histórico inmediatamente
• Usar sistemas de build o servicios de runtime fuera de Jekyll

Mantener el scope ajustado nos permitió entregar rápidamente y validar completamente.

Artefactos Clave

Todo nuestro trabajo está documentado y trazable:

• Especificación: specs/001-add-multilingual-support/spec.md
• Plan: specs/001-add-multilingual-support/plan.md
• Tareas: specs/001-add-multilingual-support/tasks.md
• Contratos: specs/001-add-multilingual-support/contracts/multilingual-routing-contract.md
• Guías Operacionales: docs/multilingual-*.md (flujo, redirecciones, rollback)

Lecciones Aprendidas

1. Clarificar primero ahorra tiempo de implementación: Al hacer cinco preguntas de alto impacto antes de codificar, evitamos retrabajo y decisiones conflictivas.

2. El orden de dependencias importa: Dividir trabajo en fases ordenadas (Setup → Fundacional → Historias de Usuario) hizo la paralelización segura y redujo bloqueadores.

3. Los documentos de especificación son artefactos vivos: Sirven doble propósito: guía de diseño y contenido de blog futuro.

4. Las convenciones de Jekyll son tu aliada: Mantenerse fiel a la estructura de Jekyll hizo la implementación directa y mantenible.

5. La validación de build es no-negociable: Ejecutar bundle exec jekyll build después de cada cambio mayor detectó issues temprano.

Próximos Pasos

• Monitorear en producción: Observar problemas de enrutamiento o SEO.
• Recopilar retroalimentación de usuarios: Ver si la UX del selector de idioma funciona bien.
• Planificar mejoras futuras: Integración de Google Analytics, idiomas adicionales, herramientas de gestión de traducciones.

Intenta Tú Mismo

Si estás construyendo un blog Jekyll y considerando soporte multilingüe, sigue este mismo flujo de trabajo:

1. Escribe una especificación clara (¿qué problemas estás resolviendo?).
2. Aclara decisiones clave con stakeholders.
3. Planifica el enfoque técnico (layouts, datos, configs).
4. Divide en tareas ordenadas con criterios de prueba.
5. Implementa y valida metódicamente.

¿El resultado? Una feature bien razonada, trazable y mantenible—más una narrativa que puedes compartir con tu audiencia.

Este post es parte de una serie sobre construir y mantener jblueprint.dev usando prácticas modernas de especificación y diseño.

In this post, I’ll walk you through the real implementation journey of jblueprint.dev using a Spec Driven Design workflow with Speckit—a framework that helps you move from feature ideas to working, validated code in a structured way.

Why Spec Driven Design?

Before touching a single line of code, we took time to:

1. Define what we wanted to build (specification).
2. Clarify ambiguities with product decisions (clarification).
3. Plan the technical approach (implementation planning).
4. Break work into ordered tasks (task generation).
5. Execute with validation (implementation).

This approach reduces rework, ensures clarity, and creates a living document trail of decisions. Perfect for a blog where you want to explain your reasoning later.

Project Context

• Project: jblueprint.dev
• Stack: Jekyll
• Goal: Add multilingual support (Spanish and English)
• i18n Plugin: jekyll-polyglot

Ground Rules

1. English-only implementation: All code and code comments are in English for maintainability.
2. Jekyll-first compliance: Follow official Jekyll conventions and documentation.
3. Build validation: Every site-affecting change requires a local bundle exec jekyll build check.

The Workflow in 5 Steps

Step 0: Foundation

We detected that the repository already had a Speckit structure (.specify/ directory) and created a project constitution that formalized our principles:

• English-only implementation artifacts
• Jekyll-first compliance for any technical decisions
• Build validation for changes affecting site output

This constitution would guide every decision forward.

Step 1: Specification & Clarification

Using speckit.specify, we created the first feature spec: “Add Multilingual Support (Spanish and English)”.

The spec defined:

• User stories: Reading in preferred language, switching language without losing context, maintaining bilingual content reliably.
• Functional requirements: URL strategy, language switching, fallback behavior, SEO.
• Success criteria: 100% of primary pages reachable in both languages, 95% successful language switches, zero broken links.

Then, using speckit.clarify, we resolved the 5 most critical product decisions:

1. URL strategy: Default language no prefix (/...); Spanish with prefix (/es/...).
2. Unsupported locale prefixes: Redirect with HTTP 301 to default-locale equivalent.
3. Missing translations: Redirect with HTTP 302 + show feedback message.
4. Language preference persistence: Session-scoped only (resets in new browser session).
5. SEO discoverability: Require reciprocal hreflang tags and x-default on bilingual pages.

Outcome: A fully clarified specification, ready for technical planning.

Step 2: Implementation Planning

Using speckit.plan, we generated design artifacts:

• plan.md — Overall strategy and phasing
• research.md — Technology deep-dives and Polyglot plugin details
• data-model.md — Localization data structures
• contracts/multilingual-routing-contract.md — Detailed URL and redirect rules
• quickstart.md — Validation checklist for developers

All artifacts enforced English-only comments and Jekyll-first thinking.

Outcome: A complete technical blueprint, testable and implementable.

Step 3: Task Generation

Using speckit.tasks, we converted the plan into an ordered backlog of 33 actionable tasks:

• Phase 1 (Setup): Install jekyll-polyglot, configure Gemfile, create locale registry.
• Phase 2 (Foundational): Configure _config.yml, create multilingual layouts and includes, wire language switching and SEO.
• Phase 3 (User Story 1): Create bilingual content (index, about, posts) and validate routes.
• Phase 4 (User Story 2): Implement language switcher with fallback and feedback.
• Phase 5 (User Story 3): Document editorial workflow for bilingual publishing.
• Phase 6 (Polish): Final validation, rollback procedures, SEO checks.

Each task had:

• Clear file paths (Jekyll-first)
• Dependencies marked
• Parallelization hints
• Independent test criteria

Outcome: A dependency-ordered, parallelizable implementation plan.

Step 4: Implementation

Using speckit.implement, we executed all 33 tasks:

Key changes:

• Added jekyll-polyglot to Gemfile and ran bundle install
• Configured multilingual locale routing in _config.yml
• Created shared includes for language switcher, SEO tags, and translation feedback
• Wrote session-based preference script in assets/js/language-session.js
• Created bilingual content: index.markdown, about.markdown, and a welcome post in both English and Spanish
• Documented redirect rules, content workflow, and rollback procedures

Validation:

• bundle exec jekyll build executed successfully
• Generated site includes bilingual routes: /index.html, /es/index.html, etc.
• hreflang tags validated on bilingual pages
• No broken internal links

Outcome: A fully functional, validated multilingual Jekyll blog.

Step 5: Rollout

We committed all changes with a clean feature branch commit, ready to merge.

Key Decisions Made

What We Didn’t Do (Non-Goals)

• Add more than two languages in this release
• Redesign the theme unrelated to language support
• Rewrite all historical content immediately
• Use non-Jekyll build systems or runtime services

Keeping scope tight allowed us to deliver quickly and validate thoroughly.

Key Artifacts

All of our work is documented and traceable:

• Specification: specs/001-add-multilingual-support/spec.md
• Plan: specs/001-add-multilingual-support/plan.md
• Tasks: specs/001-add-multilingual-support/tasks.md
• Contracts: specs/001-add-multilingual-support/contracts/multilingual-routing-contract.md
• Operational Guides: docs/multilingual-*.md (workflow, redirects, rollback)

Lessons Learned

1. Clarification upfront saves implementation time: By asking five high-impact questions before coding, we avoided rework and conflicting decisions.

2. Dependency ordering matters: Breaking work into ordered phases (Setup → Foundational → User Stories) made parallelization safe and reduced blockers.

3. Specification documents are living artifacts: They serve dual purpose: design guide and future blog post content.

4. Jekyll conventions are your friend: Staying true to Jekyll’s structure made the implementation straightforward and maintainable.

5. Build validation is non-negotiable: Running bundle exec jekyll build after every major change caught issues early.

Next Steps

• Monitor in production: Watch for any routing or SEO issues.
• Gather user feedback: See if the language switcher UX works well.
• Plan future improvements: Google Analytics integration, additional languages, translation management tools.

Try It Yourself

If you’re building a Jekyll blog and considering multilingual support, follow this same workflow:

1. Write a clear spec (what problems are you solving?).
2. Clarify key decisions with stakeholders.
3. Plan the technical approach (layouts, data, configs).
4. Break into ordered tasks with test criteria.
5. Implement and validate methodically.

The result? A well-reasoned, traceable, and maintainable feature—plus a narrative you can share with your audience.

This post is part of a series on building and maintaining jblueprint.dev using modern specification and design practices.

Objetivo

• Integrar Minimal Mistakes como tema principal.
• Mantener compatibilidad con el enrutado actual multilenguaje.
• Conservar el selector de idioma y el comportamiento de fallback existente.

Estado actual

• La especificación de esta feature está en specs/002-add-minimal-mistakes-theme/spec.md.
• La fase de clarificación ya incluye requisitos para:
  • compatibilidad con rutas default y /es/,
  • documentación de la instalación,
  • organización temporal de _posts en carpetas por mes y día.

Próximos pasos

1. Ejecutar speckit.plan para diseñar la migración de tema.
2. Generar tareas con speckit.tasks.
3. Implementar la migración validando build y rutas bilingües.

Iremos actualizando este post conforme avance la implementación.

Gem Installation

Replace minima with minimal-mistakes-jekyll in your Gemfile:

# Remove:
# gem "minima", "~> 2.5"

# Add:
gem "minimal-mistakes-jekyll"

Then run:

bundle install

_config.yml Changes

Switch the theme key

# Remove:
# theme: minima

# Add:
theme: minimal-mistakes-jekyll
minimal_mistakes_skin: default   # Options: air, aqua, contrast, dark, dirt, mint, neon, plum, sunrise

Add MM site settings

locale: en-US          # Static BCP47 for MM's internal UI strings — DO NOT use for runtime locale detection
breadcrumbs: false     # Required: MM breadcrumbs are not Polyglot locale-aware
title: your-site-title
name: "Your Name"
description: "Your site description"
url: "https://your-domain.dev"
baseurl: ""

Update exclude_from_localization

Remove the old minima asset paths and add MM’s generated asset paths:

exclude_from_localization:
  # ... other paths ...
  # Replace:
  # - assets/main.css
  # - assets/main.css.map
  # - assets/minima-social-icons.svg
  # With:
  - assets/css/main.scss
  - assets/css/main.css
  - assets/js/main.min.js

Also add specs/ to Jekyll’s exclude: list if you have spec markdown files containing MM-specific Liquid tags (include_cached) in code blocks — otherwise Jekyll will error when processing those files under minima:

exclude:
  - specs/
  # ... other paths ...

Layout Override Strategy

Minimal Mistakes provides built-in layouts that extend its default.html root layout. To inject the language switcher and hreflang metadata into every page, two files are added:

_includes/head/custom.html (new)

MM’s documented extension point for project-level <head> additions. This file is automatically included by MM’s head.html include:

```html

### `_layouts/default.html` (override)

Override MM's root layout to inject the language switcher after the masthead. All other
MM layouts (`post`, `page`, `archive`, etc.) inherit from `default`, so the switcher
appears everywhere with just this one file:

```html
---
---<!doctype html>
<html lang="en" class="no-js">
  <head>
    
<meta charset="utf-8">


<!-- begin _includes/seo.html --><title>Installing Minimal Mistakes on a Bilingual Jekyll Blog - jblueprint.dev</title>
<meta name="description" content="This post documents how to migrate a bilingual Jekyll blog from the default minima theme to minimal-mistakes-jekyll while preserving full multilingual routing via jekyll-polyglot.">



<meta property="og:type" content="article">
<meta property="og:locale" content="en_US">
<meta property="og:site_name" content="jblueprint.dev">
<meta property="og:title" content="Installing Minimal Mistakes on a Bilingual Jekyll Blog">
<meta property="og:url" content="https://jblueprint.dev/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">


  <meta property="og:description" content="This post documents how to migrate a bilingual Jekyll blog from the default minima theme to minimal-mistakes-jekyll while preserving full multilingual routing via jekyll-polyglot.">









  <meta property="article:published_time" content="2026-05-08T00:00:00+00:00">






<link rel="canonical" href="https://jblueprint.dev/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">












<!-- end _includes/seo.html -->



  <link href="/feed.xml" type="application/atom+xml" rel="alternate" title="jblueprint.dev Feed">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

<script>
  document.documentElement.className = document.documentElement.className.replace(/\bno-js\b/g, '') + ' js ';
  
</script>

<!-- For all browsers -->
<link rel="stylesheet" href="/assets/css/main.css">
<link rel="preload" href="https://cdn.jsdelivr.net/npm/@fortawesome/fontawesome-free@latest/css/all.min.css" as="style" onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@fortawesome/fontawesome-free@latest/css/all.min.css"></noscript>



    <link rel="alternate" hreflang="en" href="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">
  <link rel="alternate" hreflang="es" href="/es/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">
  <link rel="alternate" hreflang="x-default" href="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">
  </head>
  <body class="layout--post...">
    
<nav class="skip-links" aria-label="Skip links">
  <ul>
    <li><a href="#site-nav" class="screen-reader-shortcut">Skip to primary navigation</a></li>
    <li><a href="#main" class="screen-reader-shortcut">Skip to content</a></li>
    <li><a href="#footer" class="screen-reader-shortcut">Skip to footer</a></li>
  </ul>
</nav>

    <div class="masthead">
  <div class="masthead__inner-wrap">
    <div class="masthead__menu">
      <nav id="site-nav" class="greedy-nav" aria-label="Primary navigation">
        
        <a class="site-title" href="/">
          jblueprint.dev
          
        </a>
        <ul class="visible-links"><li class="masthead__menu-item">
              <a
                href="/"
                
                
              >Home</a>
            </li><li class="masthead__menu-item">
              <a
                href="/posts/"
                
                
              >Posts</a>
            </li><li class="masthead__menu-item">
              <a
                href="/about/"
                
                
              >About</a>
            </li></ul>

        
        <button class="search__toggle" type="button">
          <span class="visually-hidden">Toggle search</span>
          <i class="fas fa-search"></i>
        </button>
        

        <!-- Language switcher — EN/ES styled as masthead toggle buttons -->
        <!-- Language toggle — EN | ES integrated into MM masthead nav bar -->
<div
  class="lang-switch"
  role="navigation"
  aria-label="Language"
  data-language-switcher
  data-current-lang="en"
  data-target-en="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html"
  data-target-es="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html?translation=unavailable&requested=es"
  data-has-equivalent-en="true"
  data-has-equivalent-es="false"
  data-translation-mode="computed"
>
  <a
    href="#"
    lang="en"
    hreflang="en"
    data-language-option="en"
    class="lang-switch__btn is-active"
    aria-current="true"
  >EN</a>
  <span class="lang-switch__sep" aria-hidden="true">|</span>
  <a
    href="#"
    lang="es"
    hreflang="es"
    data-language-option="es"
    class="lang-switch__btn"
    
  >ES</a>
</div>


        <button class="greedy-nav__toggle hidden" type="button">
          <span class="visually-hidden">Toggle menu</span>
          <div class="navicon"></div>
        </button>
        <ul class="hidden-links hidden"></ul>
      </nav>
    </div>
  </div>
</div>



    <div class="language-switcher-wrapper">
      <!-- Language toggle — EN | ES integrated into MM masthead nav bar -->
<div
  class="lang-switch"
  role="navigation"
  aria-label="Language"
  data-language-switcher
  data-current-lang="en"
  data-target-en="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html"
  data-target-es="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html?translation=unavailable&requested=es"
  data-has-equivalent-en="true"
  data-has-equivalent-es="false"
  data-translation-mode="computed"
>
  <a
    href="#"
    lang="en"
    hreflang="en"
    data-language-option="en"
    class="lang-switch__btn is-active"
    aria-current="true"
  >EN</a>
  <span class="lang-switch__sep" aria-hidden="true">|</span>
  <a
    href="#"
    lang="es"
    hreflang="es"
    data-language-option="es"
    class="lang-switch__btn"
    
  >ES</a>
</div>

      <div
  id="translation-feedback"
  class="translation-feedback"
  role="status"
  aria-live="polite"
  hidden
  data-message-en="Translation not available for the selected language."
  data-message-es="Traducción no disponible para el idioma seleccionado."
>
  Translation not available for the selected language.
</div>


    </div>

    <div id="main" role="main">
      







<div id="main" role="main">
  



  <article class="page h-entry" itemscope itemtype="https://schema.org/CreativeWork">
    <meta itemprop="headline" content="Instalación de Minimal Mistakes en un blog Jekyll multilenguaje">
    <meta itemprop="description" content="Este post documenta la instalación del tema Minimal Mistakes sobre un blog Jekyll con soporte multilenguaje (en y es) basado en jekyll-polyglot.">
    <meta itemprop="datePublished" content="2026-05-08T00:00:00+00:00">
    

    <div class="page__inner-wrap">
      
        <header>
          <h1 id="page-title" class="page__title p-name" itemprop="headline">
            <a href="https://jblueprint.dev/jekyll/theme/2026/05/08/instalacion-minimal-mistakes.html" itemprop="url">Instalación de Minimal Mistakes en un blog Jekyll multilenguaje
</a>
          </h1>
          



        </header>
      

      <section class="page__content e-content" itemprop="text">
        
        <p>Este post documenta la instalación del tema <strong>Minimal Mistakes</strong> sobre un blog Jekyll con soporte multilenguaje (<code class="language-plaintext highlighter-rouge">en</code> y <code class="language-plaintext highlighter-rouge">es</code>) basado en <code class="language-plaintext highlighter-rouge">jekyll-polyglot</code>.</p>

<h2 id="objetivo">Objetivo</h2>

<ul>
  <li>Integrar Minimal Mistakes como tema principal.</li>
  <li>Mantener compatibilidad con el enrutado actual multilenguaje.</li>
  <li>Conservar el selector de idioma y el comportamiento de fallback existente.</li>
</ul>

<h2 id="estado-actual">Estado actual</h2>

<ul>
  <li>La especificación de esta feature está en <code class="language-plaintext highlighter-rouge">specs/002-add-minimal-mistakes-theme/spec.md</code>.</li>
  <li>La fase de clarificación ya incluye requisitos para:
    <ul>
      <li>compatibilidad con rutas <code class="language-plaintext highlighter-rouge">default</code> y <code class="language-plaintext highlighter-rouge">/es/</code>,</li>
      <li>documentación de la instalación,</li>
      <li>organización temporal de <code class="language-plaintext highlighter-rouge">_posts</code> en carpetas por mes y día.</li>
    </ul>
  </li>
</ul>

<h2 id="próximos-pasos">Próximos pasos</h2>

<ol>
  <li>Ejecutar <code class="language-plaintext highlighter-rouge">speckit.plan</code> para diseñar la migración de tema.</li>
  <li>Generar tareas con <code class="language-plaintext highlighter-rouge">speckit.tasks</code>.</li>
  <li>Implementar la migración validando build y rutas bilingües.</li>
</ol>

<p>Iremos actualizando este post conforme avance la implementación.</p>


        
      </section>

      <footer class="page__meta">
        
        

  

  


        


  <p class="page__date"><strong><i class="fas fa-fw fa-calendar-alt" aria-hidden="true"></i> Updated:</strong> <time class="dt-published" datetime="2026-05-08T00:00:00+00:00">May 8, 2026</time></p>


      </footer>

      

      

  <nav class="pagination" aria-label="Post pagination">
    
      <a href="#" class="pagination--pager disabled">Previous</a>
    
    
      <a href="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html" class="pagination--pager" title="Installing Minimal Mistakes on a Bilingual Jekyll Blog">Next</a>
    
  </nav>


    </div>

    
  </article>

  
  
</div>

    </div>

    <div id="footer" class="page__footer">
      <footer>
        <!-- start custom footer snippets -->

<!-- end custom footer snippets -->
        


<div class="page__footer-follow">
  <ul class="social-icons">
    

    

    
      <li><a href="/feed.xml"><i class="fas fa-fw fa-square-rss" aria-hidden="true"></i> Feed</a></li>
    
  </ul>
</div>


<div class="page__footer-copyright">&copy; 2026 <a href="https://jblueprint.dev">jblueprint.dev</a>. Powered by <a href="https://jekyllrb.com" rel="nofollow">Jekyll</a> &amp; <a href="https://mademistakes.com/work/jekyll-themes/minimal-mistakes/" rel="nofollow">Minimal Mistakes</a>.</div>

      </footer>
    </div>

    

  <script src="/assets/js/main.min.js"></script>





<script src="/assets/js/lunr/lunr.min.js"></script>
<script src="/assets/js/lunr/lunr-store.js"></script>
<script src="/assets/js/lunr/lunr-en.js"></script>








    <script src="/assets/js/language-session.js" defer></script>
  </body>
</html>

_layouts/home.html (override for bilingual post listing)

MM ships a home layout, but it does not filter posts by locale. Override it to filter site.posts by site.active_lang (the Polyglot runtime locale):

---
layout: default
---
<div class="home"><h2 class="post-list-heading">Posts</h2>
    <ul class="post-list"><li>
          <span class="post-meta">May 8, 2026</span>
          <h3>
            <a class="post-link" href="/jekyll/speckit/2026/05/08/how-to-build-a-blog-with-spec-driven-design.html">
              How to Build a Blog Using Spec Driven Design
            </a>
          </h3>
        </li><li>
          <span class="post-meta">May 8, 2026</span>
          <h3>
            <a class="post-link" href="/jekyll/speckit/2026/05/08/como-crear-un-blog-con-spec-driven-design.html">
              Cómo crear un blog con Spec Driven Design
            </a>
          </h3>
        </li><li>
          <span class="post-meta">May 8, 2026</span>
          <h3>
            <a class="post-link" href="/jekyll/theme/minimal-mistakes/2026/05/08/minimal-mistakes-integration.html">
              Installing Minimal Mistakes on a Bilingual Jekyll Blog
            </a>
          </h3>
        </li><li>
          <span class="post-meta">May 8, 2026</span>
          <h3>
            <a class="post-link" href="/jekyll/theme/2026/05/08/instalacion-minimal-mistakes.html">
              Instalación de Minimal Mistakes en un blog Jekyll multilenguaje
            </a>
          </h3>
        </li></ul></div>

Bridge layouts for standard Jekyll front matter

MM uses layout: single for posts and pages, not layout: post / layout: page. Add thin bridges so existing content continues to work:

_layouts/post.html:

---
layout: single
---

_layouts/page.html:

---
layout: single
---

Language Switcher Preservation

The existing _includes/language-switcher.html, _includes/translation-feedback.html, and assets/js/language-session.js require no changes. They are injected via the _layouts/default.html override and continue to work exactly as before the theme migration.

Navigation

Create _data/navigation.yml for MM’s masthead:

main:
  - title: "Home"
    url: /
  - title: "About"
    url: /about/

Do not embed language-switcher links here — MM navigation is a static key/URL list and does not evaluate Liquid expressions.

Post Directory Convention

New posts use the _posts/<year>/<month>/<day>/YYYY-MM-DD-title.md convention. Jekyll only uses the filename to determine date and slug; the directory structure is organizational only. Existing posts at other paths are unaffected.

Rollback Path

To restore minima without losing multilingual content:

1. Gemfile: Restore gem "minima", "~> 2.5".
2. _config.yml: Restore theme: minima; remove MM-specific keys; restore minima asset exclusions.
3. Remove _layouts/default.html, _layouts/home.html, _layouts/post.html, _layouts/page.html.
4. Remove _includes/head/custom.html and _data/navigation.yml.
5. Run bundle install && bundle exec jekyll build to verify.

All bilingual content files, routing configuration, and multilingual includes are preserved through a rollback — only the visual theme and theme-specific config keys are reverted.