REGISTRO TÉCNICO · 001
De una página a un sistema multipágina bilingüe
Una decisión de arquitectura para dejar de acumular secciones dentro de un mismo portfolio y convertirlas en rutas reales, equivalentes en español e inglés.
Cuando el problema dejó de ser agregar otra sección
El portfolio anterior funcionaba. Ya tenía una presentación en español, una versión en inglés, contenido de perfil, capacidades, proyectos y contacto. También tenía estilos propios, JavaScript modular, tema visual y algunas interacciones que valía la pena conservar.
No partí de un proyecto roto ni de una página vacía. El límite apareció al intentar hacerlo crecer. Agregar una sección nueva parecía sencillo hasta que surgió una pregunta más importante: ¿esto debe seguir siendo una parte de la misma página o ya necesita convertirse en una página real?
Mientras más contenido acumulaba, más difícil era distinguir qué pertenecía a Perfil, qué debía vivir en Proyectos y qué necesitaba Servicios o Contacto. Una modificación pequeña podía afectar una parte distinta del recorrido. La estructura seguía funcionando, pero dejó de ser una forma cómoda de revisar, ampliar y mantener el sitio.
El idioma y las rutas dejaron de ser detalles
El cambio no consistió solo en repartir contenido en carpetas. También obligó a decidir cómo debía funcionar el español y el inglés.
Antes, el idioma podía depender de sustituciones dinámicas. Para una versión pequeña del sitio eso parecía suficiente, pero al crecer surgían problemas prácticos: era más difícil revisar cada idioma por separado, enlazar una página con su equivalente y saber con claridad qué documento estaba viendo una persona.
La decisión fue mantener dos conjuntos de páginas reales: español como idioma principal y una contraparte equivalente dentro de /en/. El selector dejó de reemplazar contenido dentro del DOM y pasó a navegar hacia un documento concreto.
Eso mejoró la revisión editorial y la navegación. Más adelante también permitió añadir relaciones claras entre idiomas mediante hreflang, definir canonical propios y construir URLs independientes. El SEO técnico fue una consecuencia útil de tener rutas reales; no fue la única razón para migrar.
Qué quise conservar
La reorganización no justificaba reemplazar todo el proyecto. Había límites claros:
- Mantener HTML, CSS y JavaScript nativo.
- Conservar recursos compartidos dentro de
/assets/. - Seguir usando hosting estático.
- Mantener español e inglés como versiones públicas.
- Evitar rutas locales o comportamientos que solo funcionaran en una computadora.
- Conservar las interacciones que ya aportaban valor, pero hacerlas más claras y accesibles.
- Validar cada cambio antes de seguir con la siguiente parte del portfolio.
La intención era reorganizar una base existente, no demostrar que una herramienta nueva podía resolverlo todo.
La decisión: una página por responsabilidad
La solución fue usar carpetas por sección y un index.html dentro de cada ruta pública.
Así, /projects/ representa una página concreta de proyectos. /services/ representa una página concreta de servicios. La navegación deja de llevar a una sección escondida dentro de una página extensa y empieza a conectar documentos con propósitos definidos.
Cada página puede tener su propio título, descripción, estado activo de navegación y relación con su versión en otro idioma. Al mismo tiempo, CSS, JavaScript, imágenes e iconos permanecen compartidos cuando corresponde.
La arquitectura no convirtió el portfolio en una aplicación compleja. Hizo explícito algo que antes estaba mezclado: qué es contenido, qué es ruta y qué es componente compartido.
De una entrada concentrada a rutas independientes
Antes
index.html
└── contenido concentradoDespués
/
├── index.html
├── profile/
├── capabilities/
├── projects/
│ └── portfolio/
├── services/
├── contact/
└── en/
├── index.html
├── profile/
├── capabilities/
├── projects/
├── services/
└── contact/El diagrama resume la estructura pública. Cada directorio utiliza su propio index.html; la versión inglesa conserva rutas equivalentes dentro de /en/.
Donde la implementación se volvió concreta
La idea de “usar rutas” fue simple. Resolver sus detalles no siempre lo fue.
Una página como /profile/ y una página más profunda como /projects/portfolio/ no tienen la misma distancia hasta los recursos compartidos. Una referencia relativa correcta desde Perfil puede quedar rota desde el caso de estudio si no se ajusta su profundidad.
Eso afectó CSS, JavaScript, favicon, sprite de iconos, imágenes, enlaces internos y selector de idioma. No bastaba con comprobar Inicio: era necesario abrir las rutas por HTTP y confirmar que cada documento encontrara los recursos y destinos que le correspondían.
La navegación también tuvo que comportarse igual en todos los documentos. Cada página debía marcar su sección actual con aria-current="page", conservar un selector de idioma hacia su contraparte real y mantener controles con nombres accesibles.
En móvil, el menú necesitaba un botón real, un estado aria-expanded, cierre con Escape y retorno de foco al control que lo abrió. Al cambiar de tamaño, también tenía que corregir su estado sin quedarse abierto donde ya no correspondía.
La mejora progresiva completó esa parte. Con JavaScript, el menú puede abrirse como panel móvil y el tema puede persistir. Sin JavaScript, la navegación principal y el selector de idioma siguen disponibles. El control de tema se oculta porque no tendría una acción real: mostrarlo como si funcionara habría sido peor que dejar el tema inicial.
Lo que decidí no hacer
Había otras opciones posibles. Podía migrar a React, añadir un router, incorporar un generador estático o crear un sistema de build. Ninguna de esas herramientas era incorrecta, pero no resolvía un problema que exigiera esa complejidad en esta fase.
El portfolio ya era estático. Las rutas necesarias eran pocas, el contenido podía mantenerse como HTML real y la arquitectura no necesitaba renderizado dinámico. Añadir una capa nueva habría implicado aprender, configurar y mantener más piezas antes de comprobar si realmente hacían falta.
Por eso mantuve HTML estático, CSS compartido, JavaScript modular y rutas explícitas. Fue una decisión de proporción: usar la menor complejidad que resolviera el problema sin cerrar posibilidades de crecimiento.
Validar el sistema completo
La migración no se cerraba cuando las carpetas existían. Había que comprobar que las rutas cargaran por HTTP, que los recursos locales no devolvieran errores y que los enlaces internos llevaran al documento esperado.
También se revisaron los pares ES/EN, el estado activo de navegación, el menú móvil, el teclado, el foco visible y el comportamiento al pasar de un viewport móvil a escritorio. Los tamaños de pantalla importaban porque textos, controles y navegación podían cambiar de composición según el ancho disponible.
El contenido principal quedó disponible directamente en HTML. Eso permite leer las páginas aunque un módulo no se inicialice y evita que la arquitectura dependa de JavaScript para mostrar información básica.
Después de estabilizar esas bases, fue posible añadir canonical propios, hreflang, sitemap, robots y metadatos sociales con una relación clara entre cada URL y cada documento.
Qué ganó realmente la nueva arquitectura
La nueva estructura separó mejor las partes del portfolio. Perfil puede explicar la trayectoria; Capacidades puede organizar evidencia; Proyectos puede mostrar trabajo por contexto; Servicios puede explicar qué tipo de necesidades pueden abordarse; Contacto puede reducir fricción para iniciar una conversación.
También dejó espacio para crecer sin volver a convertir Inicio en un contenedor de todo el sitio. Un caso de estudio, una página nueva o una nota técnica pueden añadirse como rutas independientes sin alterar la función de las páginas ya publicadas.
Eso no elimina la necesidad de revisar enlaces, traducciones, responsive o accesibilidad. Hace que esos problemas tengan un lugar más claro donde encontrarse y corregirse.
Aprendizaje
La principal lección no fue que un portfolio necesita muchas páginas. Fue que la arquitectura empieza por separar lo que ya no debería seguir mezclado.
Una arquitectura mejor no necesariamente tiene más piezas. En este caso, documentos HTML reales, rutas explícitas y componentes pequeños ofrecían una solución suficiente para un portfolio bilingüe y estático.
La complejidad debe ser proporcional al problema.