Traduzindo dados externos para o idioma em que você está programando

Não tenho certeza do que fazer com o seguinte:

Nós coletamos dados de uma ferramenta externa dentro de nossa própria ferramenta. Estes dados são escritos em holandês. Estamos escrevendo nosso código Java em inglês. Devemos então traduzir esse holandês para o inglês ou mantê-lo em holandês? Por exemplo, temos 2 departamentos: Bouw (construção em inglês) e Onderhoud (manutenção em inglês).

Seria lógico criar:

public enum Department { BOUW, ONDERHOUD }

ou:

public enum Department { CONSTRUCTION, MAINTENANCE }

ou até:

public enum Afdeling { BOUW, ONDERHOUD }

(afdeling é Departamento em holandês)

Nesse cenário, eu deixaria os valores de enum em holandês:

public enum Department { BOUW, ONDERHOUD }

Porque a lógica usando essas constantes será compatível com os dados que também estão em holandês . Por exemplo, se a entrada for "bouw", o código de comparação pode se parecer com:

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

Acho mais fácil depurar quando os valores correspondem (mesmo que eu não saiba o que os valores significam). A tradução apenas adiciona um aro mental que eu, como desenvolvedor, não deveria ter que pular para provar a correção.

No entanto, você pode apenas comentar o código se isso ajudar outras pessoas a entender o contexto dos dados:

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

O inglês é uma língua franca / menor denominador comum por um motivo. Mesmo que o motivo seja conceitualmente tão fraco quanto "Todo mundo faz", esse ainda é um motivo bastante importante.

Ir contra a prática comum significa que você precisa entender holandês para entender as estruturas de dados do seu software. Não há nada errado com o holandês, mas a probabilidade de qualquer engenheiro que precisar interagir com a base de código falar ainda é menor do que a do inglês.

Portanto, se você é um Dutch somente fazer compras, e não planeja se expandir internacionalmente nunca , é quase sempre uma boa idéia para manter o seu monolingual base de código e usar a linguagem de codificação mais popular.

Nota: Este conselho se aplica apenas ao código do programa . Os dados do usuário definitivamente não devem ser traduzidos, mas processados ​​"como estão". Mesmo se você tiver um cliente "Goldstein", claramente você não deve armazenar o nome dele como "pedra dourada".

O problema é que há um continuum de termos entre "fornecido pelo usuário, não toque" e "fragmento de código, use o inglês o tempo todo". Os nomes dos clientes estão muito próximos do primeiro extremo do espectro, as variáveis ​​Java estão próximas do último final. As constantes para enumvalores estão um pouco mais distantes, principalmente se denotarem entidades externas exclusivas e conhecidas (como seus departamentos). Se todos na sua organização usarem os termos holandeses para os departamentos, você não planeja confrontar alguém com a base de código que não usa, e o conjunto de departamentos existentes muda raramente, e usar os nomes aceitos do departamento pode gerar mais sentido para constantes enum do que para variáveis ​​locais. Eu ainda não faria isso, no entanto.

Evite a tradução sempre que possível, porque toda tradução é um esforço adicional e pode apresentar bugs.

A principal contribuição do "Domain Driven Design" para a engenharia de software moderna é o conceito de uma linguagem onipresente , que é uma linguagem única usada por todos os interessados ​​em um projeto. De acordo com o DDD, a tradução não deve ocorrer dentro de uma equipe (que inclui especialistas em domínio, mesmo que presentes apenas por procuração de um documento de especificação), mas apenas entre equipes (leitura adicional: "Domain Driven Design", de Eric Evans, em particular os capítulos sobre linguagem ubíqua e design estratégico).

Ou seja, se seus especialistas em negócios (ou seu documento de especificação) falam holandês, use a terminologia (holandesa) ao expressar preocupações comerciais no código-fonte. Não traduza desnecessariamente para o inglês, pois isso cria um impedimento artificial para a comunicação entre especialistas em negócios e programadores, que leva tempo e pode (através de tradução ambígua ou incorreta) causar bugs.

Se, por outro lado, seus especialistas em negócios podem falar sobre os negócios deles em inglês e holandês, você tem a oportunidade de escolher o idioma onipresente do projeto e há razões válidas para preferir o inglês (como "internacionalmente compreensível e provavelmente mais usado pelos padrões "), mas isso não significa que os codificadores devem traduzir o que as pessoas de negócios estão falando. Em vez disso, os executivos devem mudar de idioma.

Ter uma linguagem onipresente é particularmente importante se os requisitos forem complexos e precisarem ser implementados com precisão, se você estiver apenas usando o CRUD, a linguagem usada internamente é menos importante.

História pessoal: participei de um projeto em que expusemos alguns serviços de negócios como um ponto de extremidade SOAP. O negócio foi totalmente especificado em alemão e dificilmente será reutilizado como em inglês, porque tratava de questões legais específicas de uma jurisdição específica. No entanto, alguns arquitetos de torres de marfim exigiram que a interface SOAP fosse em inglês para promover reutilização futura. Essa tradução ocorreu no hoc, e com pouca coordenação entre os desenvolvedores, ainda um glossário compartilhado, resultando no mesmo termo comercial tendo vários nomes no contrato de serviço da web e alguns termos comerciais tendo o mesmo nome no contrato de serviço da web. Ah, e é claro que alguns nomes foram usados ​​em ambos os lados da divisão - mas com significados diferentes!

Se você optar por traduzir de qualquer maneira, padronize a tradução em um glossário, adicione conformidade com esse glossário à sua definição de concluído e verifique-a em suas revisões. Não seja tão descuidado quanto nós.

A solução correta é não codificar os departamentos:

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

Ou, se você precisar absolutamente de um tipo de departamento:

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

Se você achar necessário testar departamentos específicos em seu código, precisará perguntar de maneira mais genérica o que há de especial nesse departamento e aceitar a configuração desse departamento como tendo essa propriedade. Por exemplo, se um departamento tiver uma folha de pagamento semanal, e é com isso que o código se importa, deve haver uma propriedade WEEKLY_PAYROLL que possa ser anexada a qualquer departamento pela configuração.

Para qualquer pessoa que esteja se perguntando: escolhemos a primeira opção, principalmente porque achamos que você não deve criar termos para traduzir. No entanto, se algum dia um desenvolvedor internacional estiver trabalhando no projeto, adicionamos alguma documentação para explicar isso:

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

Se você está preocupado em ter uma representação de string para mostrar ao usuário ou algo assim, basta definir uma matriz de descrições dentro de sua enumeração e expor um método.
Por exemplo: Department.BUILD.getDescription();exibirá "BOUW"

public enum Department { 
    BUILD,
    MAINTENANCE;

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

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

Eu sei que você escolheu o contrário, mas apenas no caso do vórtice do Google lançar pessoas aqui por acidente.

EDIT: Como observado por Pokechu22, você pode usar enum construtores e propriedades 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;
    }
}

o que também alcançará esse efeito.

Certos invariantes do seu código são esperados. Um desses invariantes é que um programa não se comportará de maneira diferente quando um identificador for renomeado. Nesse caso em particular, quando você tem uma enumeração e renomeia qualquer membro dessa enumeração e atualiza todos os usos desse membro, não esperaria que seu código começasse a funcionar de maneira diferente.

A análise é o processo de leitura de dados e derivação de estruturas de dados. Quando você pega os dados externos, lê-os e cria instâncias da sua enumeração, está analisando os dados. Esse processo de análise é a única parte do seu programa responsável por manter a relação entre a representação de dados como você a recebe e a forma e a nomeação dos membros de seus tipos de dados.

Como tal, não deve importar quais nomes você atribui aos membros da enum. O fato de coincidirem com as strings usadas nos dados que você lê é coincidência.

Quando você cria seu código para modelar o domínio, os nomes dos membros não devem estar relacionados ao formato de serialização dos dados. Eles não devem ser os termos holandeses, nem devem ser traduções dos termos holandeses, mas devem ser o que você decide se encaixa melhor no modelo de domínio.

O analisador que traduz entre o formato dos dados e o modelo do seu domínio. Essa é a última influência que o formato de dados deve ter no seu código.