La trampa de la traducción: lo que construir un sitio multilingüe me enseñó sobre el respeto

Creciendo en Brasil, aprendí inglés viendo series americanas con subtítulos. Recuerdo las traducciones raras. "Cool" se convertía en "legal." Los modismos se aplanaban en portugués de libro de texto. Las palabras eran correctas. La sensación estaba mal.

Veinte años después, creé un script de traducción para mi portfolio. En menos de una hora, convirtió "Next.js dashboard" en "painel do Next.js."

Me estremecí. Ningún desarrollador brasileño dice "painel." Simplemente decimos dashboard.

Estaba haciendo lo mismo que aquellos traductores de subtítulos. Convirtiendo palabras en lugar de adaptar significado.

Por qué esto importa

Las investigaciones muestran que el 75% de los usuarios de internet prefieren contenido en su idioma nativo, incluso cuando entienden inglés. No se trata de comprensión. Se trata de confianza. La sensación de "esto fue hecho para alguien como yo."

Para un portfolio, esa sensación importa. Cuando un gerente de contratación en Tokio llega a mi sitio, quiero que evalúe mi trabajo, no que traduzca en su cabeza. Cuando alguien en París lee sobre mis proyectos, quiero que piense en las ideas, no en el idioma.

Un portfolio solo en inglés envía un mensaje: "Esto es para angloparlantes primero, todos los demás después." Quería invertir eso.

Lo que la comunidad de localización me enseñó

Ese error del "dashboard" me envió a la madriguera de la localización. Leí posts de ingenieros de i18n, busqué en discusiones de GitHub y estudié cómo las grandes empresas tecnológicas manejan la traducción.

El patrón era consistente en todas las fuentes.

Las audiencias técnicas comparten un vocabulario que cruza fronteras. Los desarrolladores brasileños dicen "data pipeline," no "canalização de dados." Los ingenieros japoneses mantienen "TypeScript" como TypeScript. Los marketers franceses usan "growth marketing," no el equivalente del diccionario.

Estos términos se aprendieron en inglés. Se discuten en inglés. Traducirlos crea confusión, no claridad.

Mi script era demasiado minucioso. Estaba traduciendo cosas que deberían quedarse en inglés.

Traducción versus localización

Esta distinción se convirtió en la idea central del proyecto.

La traducción convierte palabras. La localización adapta experiencias.

Un sitio traducido dice "painel de controle" porque el diccionario lo dice. Un sitio localizado dice "dashboard" porque eso es lo que los desarrolladores brasileños realmente dicen.

Un sitio traducido convierte cada término. Un sitio localizado sabe cuándo parar. Un desarrollador en Japón necesita navegación en japonés pero espera términos técnicos en inglés. Ese equilibrio hace que el contenido se sienta nativo en lugar de traducido.

Reescribí mi enfoque. Las etiquetas de navegación se traducen. Los nombres de productos quedan en inglés. Los términos técnicos quedan en inglés. El contenido explicativo se traduce naturalmente.

Las reglas que construí

Después de corregir suficientes errores, surgieron patrones. Los documenté:

Mantener en inglés: Nombres de productos como Next.js, TypeScript, Claude. Términos de la industria como dashboard, data pipeline, growth marketing, e-commerce. Secciones de habilidades y nombres de certificaciones.

Traducir: Elementos de navegación, etiquetas de formularios, contenido narrativo, títulos de secciones.

Adaptaciones específicas por idioma:

Para portugués, usar "dashboard" no "painel," usar "template" no "modelo." Los desarrolladores brasileños aprendieron estos términos en inglés y los usan diariamente.

Para español, usar "dashboard" no "cuadros de mando," usar "marketers" no "vendedores," usar "data pipelines" no "canalizaciones de datos."

Para japonés, mantener nombres de productos en inglés (Next.js, no ネクストジェイエス). Katakana funciona para préstamos comunes como ダッシュボード (dashboard).

Para francés, usar "dashboard" no "tableaux de bord," usar "marketers" no "spécialistes du marketing."

Estas reglas viven en la documentación de mi proyecto ahora. Cada vez que traduzco contenido, las reviso.

Cuando todo encajó

La primera vez que cargué mi sitio en japonés, algo cambió.

No hablo japonés. No puedo leerlo más allá de unos pocos caracteres. Pero ahí estaba: mi portfolio, mis proyectos, en un idioma que no conozco.

La navegación decía "プロジェクト" (proyectos). El cuerpo del texto fluía en japonés. Pero "Next.js" seguía siendo "Next.js." "TypeScript" seguía siendo "TypeScript." El equilibrio se sentía correcto.

Contenido escrito para cada audiencia, no traducido para ellos. Esa distinción captura todo lo que aprendí.

El costo de no hacer esto

La mayoría de los portfolios que veo son solo en inglés. Está bien. El inglés es la lengua franca de la tecnología.

Pero cuando alguien llega a tu sitio y tiene que hacer traducción mental, has añadido fricción. Pueden irse más rápido. Pueden entender menos. Pueden confiar menos. Esa carga cognitiva es invisible pero real.

Un sitio multilingüe dice: "Pensé en ti. Hice esto para ti. Tu contexto importa."

En un campo donde cada portfolio usa los mismos frameworks y muestra proyectos similares, esa consideración destaca.

La parte técnica, brevemente

El sistema usa next-intl para el enrutamiento y la API de DeepL para traducción inicial. Escribí scripts que procesan archivos MDX, preservan el frontmatter y aplican reglas de localización. Todo el proceso se ejecuta en menos de 30 segundos.

Pero la traducción automática es solo el primer paso. Después de que DeepL genera la versión inicial, le pido a Claude que revise cada traducción contra las mejores prácticas de localización. Claude identifica términos que deben quedarse en inglés, corrige frases extrañas y asegura que el vocabulario técnico coincida con lo que los desarrolladores realmente usan en cada idioma.

Esa combinación de velocidad y calidad importa. Si la localización tomara horas de trabajo manual, dejaría de hacerlo.

Para detalles técnicos, ve la página del proyecto. Este post es sobre el viaje.

Lo que aprendí

Empecé pensando en alcance. Más idiomas, más visitantes, mejor SEO. Esas cosas son verdad, pero no son el punto.

La verdadera lección fue empatía. Construir para una audiencia global me obligó a pensar en personas cuyo contexto no comparto.

Para portugués, tenía ventaja. Soy hablante nativo. Puedo detectar la incomodidad inmediatamente. Para japonés y francés, tuve que confiar en lo que la comunidad de localización ha documentado. Lo que posts de blogs y guías de estilo dicen sobre cómo las audiencias técnicas realmente se comunican.

Esa dependencia del conocimiento externo es humillante. No puedes asumir que tus valores predeterminados son universales. Tienes que encontrar a las personas donde están.

Una invitación permanente

Las traducciones en este sitio no son perfectas. La traducción automática es un punto de partida. Los hablantes nativos captan matices que los algoritmos pierden.

Si lees algo en portugués, español, japonés o francés que suene raro, avísame a través del formulario de contacto. Lo apreciaría.

La localización nunca está terminada. Es una conversación continua entre quien construye y la audiencia. Construir para una audiencia global significa estar abierto a feedback de personas que conocen su contexto mejor de lo que tú jamás lo conocerás.