Primeiro quero reforçar que não estou tentando ofender ninguem, nem menosprezar o valor da API
ou dos seus criadores. O ponto é mais geral que isso. A escolha que vc fizerem pelo menos é consistente, mas este
tipo de decisão tem que ser feita a diário no pais todo.
A vossa posição é que existem palavras especiais como get, set ,with , etc… que correspondem com certos padrões
e palavras que correspondem com o dominio, como Boleto ou Banco.
Isso é inaceitável. E essa é o vosso problema. Vcs aceitam que existe essa diferença e ai começa o problema
Essa diferença não existe. Utilizar mais do que uma lingua numa API é uma gambiarra. Aceitem isso.
A defesa de usar duas linguas é porque “não é possivel traduzir todos os termos”. Possivel é, a questão é se o cara que escreve a API sabe traduzir todos os termos. Esse é o real problema. Para que essa pessoa não precise de um mestrado em inglês recorre-se à gambiarra de definir os termos “intradutiveis” em portugues.
Numa API como essa que se destina apenas a funcionalidades brasileiras nem é tão grave assim, mas isso automaticamente destroi a utilidade internacional da API. Afinal , todos os programas usados no brasil são escritos por brasileiros ?
Alguem já tentou utilizar uma API inglês-alemão com javadoc em alemão ? É muiiito dificil. Se todos os projetos opnesource fossem
criados nas linguas dos seus autores o mundo opensource seria um fracasso.
O get, set, etc… não são independentes de lingua, mas como os autores das outras API (componente que utiliza reflection, tipo spring para injetar valores, por exemplo) dicidiram pelo inglês, então temos que manter essa compatibilidade. Mas se o cara tivesse dicidido no inicio utilizar a sua lingua ( se o Spring não fosse escrito em ingles ou o padrão Java Bean não tivesse sido criado em ingles …) estariamso utilizando outos prefixos e sufixos.
O ponto é que o ingles é a lingua padrão para o desenvolvimento de API ( não estou falando de sistema completos ainda)
e portanto não faz sentido liberar uma API que não segue esse padrão. O problema de traduzir as palavras é irrelevante porque isso é uma limitação da equipe. É o mesmo tipo de limitação como se a equipe não soubesse java, ou conhecesse o padrão Java Bean
Qual é o problema disso ? BancoDoBrasil é um nome próprio. Não se traduz. Ou você traduziria Bank of New York ?
(Banco de Nova … o quê ?)
imagine a hierarquia Heroi <- Batman , ou vc vai traduzir para Heroi <- HomemMorcego ?
Mas Boleto não é um nome próprio. E voce poderia chamar-lhe o que vc quiser já que é vc que está fazendo o dominio da sua API.
Se vc chamar de PaymentTitle alguem o vai contradizer ?
Além do mais, tem a velha historia de Boleto vs Bloqueto. Vc escolheu Boleto e ninguem refilou disso. Isso significa que vc pode chamar oque vc quiser. Claro que vc vai tentar chamar coisas mnemonicas , mas em caso de duvida existe o Javadoc para esplicar o conceito. Por exemplo, até hoje ainda não entendi porque Date tem informações de hora. Mas foi escolhido assim, e é justificado no javadoc, então estão tudo certo.
Não estou dizendo que é facil criar essa tradução para todos os itens, estou dizendo que tem que haver um esforço.
Afinal vc decidiu seguir o padrão “get/set” , mas não o padrão “escreva em ingles para todo o mundo entender”. E a decisão
parece ser apenas baseada na preguiça ou no desconhecimento. Isso que é triste. Porque existem outras opções.
Como disse antes, o meu comentário não se refere apenas à API em epigrafe, mas a todas as API criadas no Brasil que cometem o erro de achar que só brasileiro ( ou pelo menos pessoas que entender portugues) as irão usar pois ninguem mais no mundo tem necessidade delas. Imagine se os caras da suiça (onde existem 3 linguas) tentarem fazer o mesmo, teremos 3 API ? Vc gostaria /usaria de uma API em italiano para controlar os documentos suiços ? E que tal uma API em chines ou arabe ?
