Cartera multilingüe: Llegar a un público global

Por qué es importante la lengua

He aquí una cifra que cambió mi forma de pensar sobre la web: El 75% de los internautas prefieren comprar productos en su lengua materna. Incluso cuando entienden el inglés, confían más en los contenidos en su propia lengua. Permanecen más tiempo. Se implican más.

Para una cartera, esta idea tiene peso. Un responsable de contratación en São Paulo que escanee mi trabajo no debería tener que traducir mentalmente mientras evalúa mis habilidades. Un posible colaborador de Tokio debería sentir que el sitio se ha creado pensando en él. El lenguaje no es sólo comprensión. Tiene que ver con el respeto, la confianza y la sensación de que perteneces a este lugar.

Una cartera sólo en inglés envía un mensaje involuntario: "Esto es para angloparlantes primero, para todos los demás después". Yo quería darle la vuelta a eso. Quería que visitantes de Brasil, España, Japón y Francia aterrizaran en mi sitio y pensaran: "Oh, esta persona lo entiende".

Traducción vs. Localización: Una distinción crítica

Al principio de este proyecto, aprendí algo que la mayoría de la gente pasa por alto: la traducción y la localización no son lo mismo.

La traducción convierte palabras de un idioma a otro. Es algo mecánico. "Ponte en contacto conmigo" se convierte en "Contáctame" en español. Hecho.

La localización adapta toda la experiencia a una cultura concreta. Tiene en cuenta el contexto, las expectativas y las convenciones. Un sitio localizado no sólo intercambia palabras. Se siente nativo.

Aquí es donde esta distinción importa en tecnología: un desarrollador brasileño que lea sobre "canalizaciones de datos" espera ver "canalizaciones de datos", no "canalizações de dados". El término inglés es estándar en la industria. Traducirlo resultaría incómodo, incluso condescendiente. Del mismo modo, "dashboard" sigue siendo "dashboard" porque así es como lo llaman los desarrolladores de São Paulo, Tokio y París.

La localización significa saber cuándo NO traducir. Significa comprender que los lectores japoneses esperan "Next.js" y "TypeScript" en inglés, pero etiquetas de navegación en japonés. Significa reconocer que un vendedor francés utiliza "marketing de crecimiento" en la conversación, no "marketing de croissance".

Esta percepción dio forma a todo el sistema. No estaba construyendo una herramienta de traducción. Estaba construyendo un motor de localización que utiliza la traducción de forma estratégica.

El reto

La localización manual no es escalable. Contratar traductores para cada entrada del blog, actualización del proyecto y cambio de la interfaz de usuario crearía un cuello de botella. Peor aún, me ralentizaría lo suficiente como para dejar de publicar en varios idiomas. La carga del mantenimiento ganaría.

Necesitaba un sistema con tres propiedades:

1. Velocidad. Los nuevos contenidos debían localizarse en minutos, no en días.
2. Inteligencia. El sistema debe saber qué traducir y qué conservar.
3. Resiliencia. Las traducciones incompletas nunca deben estropear el sitio.

La solución

La arquitectura combina next-intl para un enrutamiento consciente de la localización con la API de traducción de DeepL para una traducción automática de alta calidad. Un canal de traducción personalizado se encarga de los matices.

La experiencia del visitante:

Cuando alguien llega, el sistema detecta el idioma de su navegador. Si están configurados en portugués, ven /pt-BR/blog con contenido en portugués. Los visitantes japoneses ven /ja/projects con texto en japonés. La estructura de URL es limpia, legible y compatible con los motores de búsqueda.

Si una página concreta aún no se ha traducido, los visitantes ven la versión en inglés en lugar de un error. Este retroceso se produce de forma silenciosa. No hay páginas rotas, ni mensajes de "traducción en breve". Sólo contenido.

El flujo de trabajo del contenido:

Lo escribo todo una vez en inglés. Un script de traducción procesa el contenido a través de DeepL, aplica reglas de localización y genera archivos específicos para la localización. Todo el proceso se ejecuta en menos de 30 segundos.

Cómo funciona el script de traducción

El script gestiona tanto las cadenas de la interfaz de usuario (botones, navegación, mensajes de error) como el contenido de formato largo (entradas de blog, descripciones de proyectos, la página "Acerca de"). Conserva la estructura de la portada, mantiene el formato Markdown y deja intactos los bloques de código.

El proceso:

1. Lee los archivos fuente en inglés (MDX o JSON)
2. Extraer el contenido traducible conservando la estructura
3. Envía el texto a la API DeepL con el idioma de destino
4. Aplicar reglas de localización (conservar términos técnicos, nombres de productos)
5. Escribe archivos específicos para la localización (por ejemplo, post.pt-BR.mdx)

Reglas de localización en la práctica

El sistema sigue reglas explícitas sobre qué traducir y qué conservar:

Traducir siempre:

• Etiquetas de navegación e IU
• Contenido y descripciones de los artículos
• Campos de formulario y mensajes de error
• Llamadas a la acción

Conservar siempre en inglés:

• Nombres de productos: Next.js, TypeScript, DeepL, Cursor
• Nombres de empresas: Nike, Meta, Rocket Internet
• Términos técnicos: API, dashboard, data pipeline, template
• Ejemplos de código y rutas de archivos

Adaptaciones específicas de idioma:

• Portugués (Brasil): "dashboard" no "painel", "template" no "modelo"
• Español: "marketers" no "vendedores", "data pipelines" no "canalizaciones de datos"
• Japonés: Nombres de productos en inglés, préstamos comunes en katakana
• Francés: "dashboard" no "tableaux de bord", CTA naturales como "Contactez-moi"

Estas reglas producen traducciones que resultan naturales para los lectores expertos en tecnología de cada país. El contenido se lee como si hubiera sido escrito para ellos, no traducido para ellos.

Resultados

Para los visitantes:

• Contenido disponible en 5 idiomas desde el primer día
• Detección automática del idioma en función de la configuración del navegador
• Experiencia coherente en todas las páginas e idiomas
• Sin callejones sin salida, páginas rotas o mensajes de "contenido no disponible"

Para los motores de búsqueda:

• URL únicas e indexables para cada idioma (/en/blog, /ja/blog, /pt-BR/blog)
• Etiquetas hreflang adecuadas para una indexación lingüística precisa
• Mejor visibilidad en los resultados de búsqueda locales en varios países

Para un mantenimiento continuado:

• Nuevo contenido localizado en menos de 30 segundos
• Una única fuente de verdad en inglés
• Sin gestión manual de archivos por idioma
• Publicación segura mientras se realizan las traducciones

Lo que aprendí

Construir este sistema me enseñó que la localización es una decisión de producto, no sólo técnica. Cada elección sobre qué traducir (y qué no) refleja una comprensión de la audiencia.

La mayor enseñanza: respeta la experiencia de tus usuarios. Un desarrollador en Japón no necesita "TypeScript" traducido al japonés. Necesita que el contenido que lo rodea resulte natural en su idioma. Conseguir este equilibrio es la diferencia entre un sitio que parece traducido y uno que parece nativo.

Esta cartera llega ahora a un público global sin la sobrecarga de mantener bases de código separadas para cada idioma. Y lo que es más importante, muestra a los visitantes que su idioma y su contexto me importan. En un sector en el que todos los portafolios tienen el mismo aspecto, eso importa.

Nota sobre las traducciones

Las traducciones de este sitio se generan utilizando la API de DeepL, y luego se revisan y perfeccionan según las directrices de localización descritas anteriormente. La traducción automática es un punto de partida, no un producto acabado.

Si observas que algo se lee mal en tu idioma o tienes sugestiones para mejorarlo, agradeceré tus comentarios a través del formulario de contacto. La localización es un proceso continuo, y los hablantes nativos captan matices que la automatización pasa por alto.