Traducción de datos externos al lenguaje en el que está programando

No estoy seguro de qué hacer con lo siguiente:

Tomamos datos de una herramienta externa dentro de nuestra propia herramienta. Estos datos están escritos en holandés. Estamos escribiendo nuestro código Java en inglés. ¿Deberíamos traducir este holandés al inglés o mantenerlo holandés? Por ejemplo, tenemos 2 departamentos: Bouw (Construcción en inglés) y Onderhoud (Mantenimiento en inglés).

¿Sería lógico crear:

public enum Department { BOUW, ONDERHOUD }

o:

public enum Department { CONSTRUCTION, MAINTENANCE }

o incluso:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling es departamento en holandés)

En este escenario, dejaría los valores de enumeración en holandés:

public enum Department { BOUW, ONDERHOUD }

Porque la lógica que usa estas constantes coincidirá con los datos que también están en holandés . Por ejemplo, si la entrada es "bouw", el código de comparación podría verse así:

if (Department.BOUW == input.toUpper())

Me resulta más fácil depurar cuando los valores coinciden (incluso si no sé lo que significan los valores). La traducción solo agrega un aro mental que, como desarrollador, no debería tener que saltar para probar la corrección.

Sin embargo, puede comentar el código si ayuda a otros a comprender el contexto de los datos:

public enum Department { 
    BOUW, /* build */
    ONDERHOUD /* maintenance */
}

El inglés es una lengua franca / mínimo común denominador por una razón. Incluso si la razón es conceptualmente tan débil como "Todos lo hacen", sigue siendo una razón bastante importante.

Ir en contra de la práctica común significa que tienes que entender el holandés para entender las estructuras de datos en tu software. No hay nada malo con el holandés, pero la probabilidad de que cualquier ingeniero que tenga que interactuar con la base de código lo hable es aún menor que eso para el inglés.

Por lo tanto, a menos que seas un holandés única tienda, y no tiene intención de expandirse internacionalmente vez , es casi siempre una buena idea para mantener su base de código monolingüe, y utilizar el lenguaje de codificación más popular.

Nota: Este consejo se aplica solo al código del programa . Los datos del usuario definitivamente no deben traducirse, sino procesarse "tal cual". Incluso si tiene un cliente "Goldstein", claramente no debe almacenar su nombre como "piedra dorada".

El problema es que hay un continuo de términos entre "proporcionado por el usuario, no tocar" y "fragmento de código, use inglés en todo momento". Los nombres de los clientes están muy cerca del extremo anterior del espectro, las variables de Java cerca del último extremo. Las constantes para los enumvalores están un poco más lejos, particularmente si denotan entidades externas únicas y conocidas (como sus departamentos). Si todos en su organización usan los términos holandeses para los departamentos, no planea confrontar a nadie con la base de código que no lo hace, y el conjunto de departamentos existentes cambia raramente, entonces usar los nombres aceptados del departamento puede hacer más sentido para constantes enum que para variables locales. Sin embargo, todavía no lo haría.

Evite la traducción cuando sea posible, porque cada traducción es un esfuerzo adicional y puede introducir errores.

La contribución clave del "diseño impulsado por dominio" a la ingeniería de software moderna es el concepto de un lenguaje ubicuo , que es un lenguaje único utilizado por todos los interesados ​​en un proyecto. De acuerdo con DDD, la traducción no debe ocurrir dentro de un equipo (que incluye expertos en dominios, incluso si está presente solo por proxy de un documento de especificación), sino solo entre equipos (lectura adicional: "Diseño impulsado por dominio" por Eric Evans, en particular los capítulos sobre lenguaje ubicuo y diseño estratégico).

Es decir, si sus expertos comerciales (o su documento de especificación) hablan holandés, use su terminología (holandesa) cuando exprese inquietudes comerciales en el código fuente. No traduzca innecesariamente al inglés, ya que hacerlo crea un impedimento artificial para la comunicación entre expertos en negocios y programadores, lo que lleva tiempo y puede (a través de una traducción ambigua o mala) causar errores.

Si, por el contrario, sus expertos en negocios pueden hablar sobre sus negocios tanto en inglés como en holandés, se encuentra en la afortunada situación de poder elegir el idioma omnipresente del proyecto, y hay razones válidas para preferir el inglés (como "comprensible internacionalmente y es más probable que lo usen los estándares "), pero hacerlo no significa que los codificadores deban traducir lo que hablan los empresarios. En cambio, los empresarios deberían cambiar de idioma.

Tener un lenguaje ubicuo es particularmente importante si los requisitos son complejos y deben implementarse con precisión, si solo estás haciendo CRUD, el lenguaje que utilizas internamente es menos importante.

Anécdota personal: estaba en un proyecto donde expusimos algunos servicios comerciales como un punto final SOAP. El negocio se especificó por completo en alemán, y es poco probable que se reutilice como en inglés, porque se trataba de asuntos legales específicos de una jurisdicción en particular. Sin embargo, algunos arquitectos de la torre de marfil ordenaron que la interfaz SOAP sea en inglés para promover la reutilización futura. Esta traducción se produjo de manera puntual y con poca coordinación entre los desarrolladores, pero solo un glosario compartido, lo que dio como resultado que el mismo término comercial tuviera varios nombres en el contrato de servicio web y algunos términos comerciales que tuvieran el mismo nombre en el contrato de servicio web. Ah, y por supuesto, algunos nombres se usaron a ambos lados de la división, ¡pero con diferentes significados!

Si elige traducir de todos modos, estandarice la traducción en un glosario, agregue el cumplimiento de ese glosario a su definición de hecho y verifíquelo en sus comentarios. No seas tan descuidado como lo hemos sido nosotros.

La solución correcta es no codificar los departamentos en absoluto:

ArrayList<String> departments = (... load them from a configuration file ...)

O, si realmente necesita un tipo de departamento:

class Department { String name; Department(String name) { this.name = name; } ... }
HashMap<String, Department> = (... generate from configuration file ...)

Si encuentra la necesidad de probar con departamentos específicos en su código, debe preguntar más genéricamente qué tiene de especial ese departamento y aceptar configurar ese departamento como que tiene esa propiedad. Por ejemplo, si un departamento tiene una nómina semanal, y eso es lo que le importa al código, debe haber una propiedad WEEKLY_PAYROLL que la configuración pueda adjuntar a cualquier departamento.

Para cualquier persona que se pregunte: hemos elegido la primera opción, principalmente porque creemos que no debe inventar términos por el simple hecho de traducir. Sin embargo, si en algún momento un desarrollador internacional estaría trabajando en el proyecto, hemos agregado documentación para explicarlo:

/** The possible departments of a project, given in the Dutch language. */
public enum Department { BOUW, ONDERHOUD }

Si le preocupa tener una representación de cadena para mostrar al usuario o algo, simplemente defina una matriz de descripciones dentro de su enumeración y exponga un método.
Por ejemplo: Department.BUILD.getDescription();generará "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

    private String[] descriptions = new String[] {
        "BOUW",
        "ONDERHOUD"
    };

    public String getDescription() {
        return descriptions[ordinal()];
    }
}

Sé que elegiste lo contrario, pero en caso de que el vórtice de Google arroje a la gente aquí por accidente.

EDITAR: Como lo señaló Pokechu22 , puede usar constructores enum y propiedades privadas como esta:

public enum Department {
    BUILD("BOUW"),
    MAINTENANCE("ONDERHOUD");

    private final String description;

    private Department(String description) {
        this.description = description;
    }

    public String getDescription() {
        return description;
    }
}

que también logrará ese efecto.

Se espera que ciertos invariantes de su código se mantengan. Uno de esos invariantes es que un programa no se comportará de manera diferente cuando se cambie el nombre de un identificador. En este caso en particular, cuando tiene una enumeración, y cambia el nombre de cualquier miembro de esa enumeración, y actualiza todos los usos de ese miembro, no esperaría que su código comience a funcionar de manera diferente.

El análisis es el proceso de leer datos y derivar estructuras de datos a partir de ellos. Cuando toma los datos externos, los lee y crea instancias de su enumeración, está analizando los datos. Ese proceso de análisis es la única parte de su programa responsable de mantener la relación entre la representación de datos de cómo la recibe y la forma y el nombre de los miembros de sus tipos de datos.

Como tal, no debería importar qué nombres asignes a los miembros de la enumeración. Que coincidan con las cadenas utilizadas en los datos que lee es una coincidencia.

Cuando diseña su código para modelar el dominio, los nombres de los miembros no deben estar relacionados con el formato de serialización de los datos. No deberían ser los términos holandeses, ni deberían ser traducciones de los términos holandeses, pero deberían ser lo que usted decida que se ajusta mejor al modelo de dominio.

El analizador que se traduce entre el formato de datos y su modelo de dominio. Esa es la última influencia que el formato de datos debería tener en su código.