Cuando desarrollamos una aplicación, surge una pregunta clave: ¿en qué idioma deben estar sus términos, documentación y código? Aunque el inglés es el estándar global en tecnología, en contextos donde el negocio no opera en inglés, la decisión no es tan simple.

En este artículo exploraremos cuándo es conveniente mantener el idioma original y cuándo es mejor adoptar el inglés, basándonos en enfoques prácticos y en el Diseño Orientado a Dominios (Domain-Driven Design, DDD).

Contexto: ¿Quiénes son los stakeholders?

La elección del idioma no es arbitraria; debe alinearse con los actores involucrados:

Caso 1: Aplicación en inglés, stakeholders internacionales
Si la aplicación se dirige a un mercado global y la mayoría de los equipos (negocio, desarrollo, operaciones, usuarios) usan el inglés, lo lógico es que toda la documentación y terminología se mantengan en ese idioma. Esto evita traducciones innecesarias y garantiza alineación con estándares internacionales.

Caso 2: Aplicación en español, stakeholders hispanohablantes
Si la aplicación está enfocada en un mercado hispanohablante y todos los equipos trabajan en español, forzar términos en inglés solo genera fricción y confusión. Mantener el idioma nativo en la documentación y el dominio facilita la comunicación.

El Problema de Traducir sin Contexto: El Caso «Microsoft MVP Award»

Uno de los errores más comunes al traducir términos técnicos y de negocio es perder el significado original. Un ejemplo claro es «Microsoft MVP Award«, que a menudo se traduce erróneamente como «Premio MVP de Microsoft», cuando la traducción más precisa sería «Galardón Microsoft MVP».

¿Por qué?

  • Premio implica una competencia con ganadores y perdedores.
  • Galardón es un reconocimiento a la trayectoria y contribución de una persona.

Si alguien traduce mal «Award» en este contexto, puede transmitir una idea equivocada. Ahora imagina que más adelante necesitas volver a traducirlo al inglés. Si partimos de una mala traducción en español, podríamos cometer un error aún mayor, como:

«Microsoft MVP Prize»

Cuando «Prize» implica un premio monetario o por competencia.

Este mismo problema ocurre al traducir términos de negocio en software sin considerar el contexto original.

Lenguaje Ubicuo y el Idioma del Dominio

En el desarrollo de software, surge otra pregunta recurrente: ¿El código debe estar en inglés, en el idioma del negocio o en una combinación de ambos?

Aquí es donde entra en juego el concepto de Lenguaje Ubicuo (Ubiquitous Language), un pilar fundamental de DDD.

¿Qué es el Lenguaje Ubicuo?

Es un lenguaje compartido entre todos los involucrados en un proyecto (desarrolladores, analistas, negocio, QA, etc.), que describe los conceptos del dominio de la misma manera en todos los niveles: código, documentación, diagramas y comunicación.

¿Qué implica esto?

  • Si el negocio usa términos en español, el código también debe reflejar esos términos en español.
  • Si el negocio opera en inglés, entonces el código debe mantenerse en inglés.

En DDD, el modelo de dominio debe ser una representación fiel del negocio, no una traducción arbitraria al inglés solo por costumbre. Traducir términos sin una razón clara puede generar confusión y pérdida de información, especialmente en empresas donde los equipos de negocio no están familiarizados con el inglés técnico.

Ejemplo: Aplicando Lenguaje Ubicuo en Código

Si estamos desarrollando una aplicación en español para una empresa que otorga reconocimientos, un diseño alineado con DDD respetaría los términos exactos del negocio:

// Capa de Dominio: Si la Web del MVP fuera para una empresa española y no saldrá a global  
public class GalardonMVP  
{  
    public string Nombre { get; }  
    public string Apellidos { get; }  
    public DateTime FechaGalardon { get; }  
    public string TipoGalardon { get; }  
  
    public GalardonMVP(string nombre, string apellidos, DateTime fechaGalardon, 
string tipoGalardon)  
    {  
        Nombre = nombre;  
        Apellidos = apellidos;  
        FechaGalardon = fechaGalardon;  
        TipoGalardon = tipoGalardon;  
    }  
}  
  
public class RegistroGalardonAggregate  
{  
    public GalardonMVP Galardon { get; }  
  
    public RegistroGalardonAggregate(GalardonMVP galardon)  
    {  
        Galardon = galardon;  
    }  
}

Aquí, el dominio está en español porque refleja exactamente los conceptos del negocio.

Para los comandos y la capa de aplicación (como el Aggregate anterior), podemos usar sufijos en inglés por legibilidad:

public class RegistrarGalardonMVPCommand : ICommand  
{  
    public string Nombre { get; }  
    public string Apellidos { get; }  
    public DateTime FechaGalardon { get; }  
    public string TipoGalardon { get; }  
}

Esta mezcla mantiene el código claro y alineado con la terminología del negocio, sin perder la conexión con el mundo técnico.

¿Y los sufijos en inglés?

El uso de términos como Command, Event o Repository en inglés viene de convenciones técnicas establecidas en la comunidad de desarrollo. Algunos equipos (y es mi caso) prefieren usarlos para que el código sea más reconocible a nivel técnico, incluso si el dominio está en otro idioma.

Sin embargo, en DDD puro, el código debe hablar el mismo idioma que el negocio. Así que si todo el dominio está en español, también los sufijos pueden estar en español (Comando, Evento, Repositorio).

No es una regla estricta, sino una decisión de equipo. Si el equipo está cómodo con Command, Event, etc., se pueden mantener en inglés. Pero si queremos máxima coherencia con el negocio, lo mejor es que todo esté en español.

Pero si ya tenemos más partes técnica susando palabras en ingles como: frameworks, integrations, services, etc. No veo la razón de evitar usar esos sufijos en ingles.

El Idioma Debe Alinearse con el Contexto
  • Si la aplicación y los stakeholders son internacionales, usemos inglés en todo.
  • Si la aplicación y los stakeholders son hispanohablantes, el dominio debe estar en español.
  • Si traducimos términos sin contexto, corremos el riesgo de perder información y generar errores aún mayores en futuras traducciones.

Pero lo más importante es aplicar el principio del Lenguaje Ubicuo:

  • El dominio debe expresarse en el mismo idioma que usan los expertos del negocio.
  • El código debe ser una representación directa del lenguaje del negocio, sin traducciones arbitrarias.

Este artículo no busca llamar la atención sobre la traducción del Microsoft MVP Award… ¡o sí! 😆 Pero sobre todo, responde a una pregunta que incluso muchos seniors me han hecho:

«Jose María, he visto que el DDD está en X idioma…»

Créeme, cuando trabajas con equipos de diferentes países/lenguajes, es sorprendente cómo todos se llevan las manos a la cabeza cuando ven que DDD está en el idioma nativo de una aplicación que nunca saldrá a nivel global.

¿Estás pensado en aplicar esta recomendación en tu equípo?

En ese caso te recomiendo este enfoque práctico:

Análisis del Contexto del Negocio

Primero, identifica el idioma que usan los expertos del dominio (Product Owners, analistas, usuarios finales, etc.). Pregunta:

  • ¿En qué idioma hablan sobre el negocio y sus procesos?
  • ¿Los términos clave del dominio tienen un equivalente claro en inglés o solo en español?

Ejemplo: Si tu equipo trabaja en una aplicación de recursos humanos para un mercado hispanohablante, términos como «Nomina», «Horas Extra» o «Vacaciones» deberían mantenerse en español para alinearse con el negocio.

Definición del Lenguaje Ubicuo

Organiza un workshop de Lenguaje Ubicuo con desarrolladores y expertos del negocio para:

  • Identificar términos clave del dominio.
  • Acordar el idioma de esos términos en código, documentación y comunicación diaria.

Ejemplo: Si están desarrollando una funcionalidad de «Reconocimientos», podrían acordar que el término será «Galardón» en lugar de traducirlo a «Award», ya que refleja mejor el concepto del negocio.

Aplicación en Código y Documentación

  • Código de Dominio en el Idioma del Negocio: Las entidades, agregados y servicios del dominio deberían usar los términos exactos que usan los expertos del negocio.
  • Sufijos Técnicos en Inglés (Opcional, en mi caso es obligatorio): Manten los términos técnicos en inglés como Service, Repository o Command para alinear con convenciones comunes.

Documentación y Comunicación Consistente

  • Documentación de Negocio: En el idioma del negocio (en este ejemplo, en español).
  • Comentarios en el Código: Puedes usar inglés para mantener consistencia con convenciones técnicas globales, pero los términos del dominio deben seguir en español.
  • Revisiones de Código y Reuniones Técnicas: Fomenta el uso del Lenguaje Ubicuo en las discusiones técnicas para evitar malentendidos.

Evaluación Continua y Feedback

Después de implementar estos cambios:

  • Recoge feedback de los desarrolladores y expertos del negocio para ajustar el Lenguaje Ubicuo según sea necesario.
  • Revisa el impacto en la productividad y en la claridad de la comunicación.