Caelum Stella - utilidades para o desenvolvedor brasileiro open source!

show de bola!

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1663 Offline

lavh wrote:
Tentar traduzir tudo pra inglês fica tosco com algumas palavras. Ou alguém sabe como traduzir CARTEIRA para inglês? E colocar pegarXXX seria horrível.

PS: Carteira no sentido bancário e não carteira que você põe no bolso.

normlamente é Portfolio, mas pode ser Account dependendo do conceito do sistema

Forum Spammer Membro desde: 22/03/2005 20:57:48 Mensagens: 1663 Offline

Paulo Silveira wrote:
Brincadeiras a parte, foi realmente uma decisao dificil.

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

Teriamos interface Bank e ai BancoDoBrasil implements Bank....

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 ?

Obrigado pela opinião Sérgio.

Não vou comentar o que você disse, porque não acho que valha a pena. Opinião cada um tem a que quiser e eu já disse os nossos motivos para a escolha dos nomes.
Quero só deixar bem claro que nossa decisão não foi por preguiça e muito menos por ignorância.

This message was edited 2 times. Last update was at 28/05/2008 14:20:21

sergiotaborda wrote:
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.

bom que avisou...

sergiotaborda wrote:
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.

sergiotaborda wrote:
Para que essa pessoa não precise de um mestrado em inglês recorre-se à gambiarra de definir os termos "intradutiveis" em portugues.

sergiotaborda wrote:
O problema de traduzir as palavras é irrelevante porque isso é uma limitação da equipe.

Muito gentis tuas palavras...

sergiotaborda wrote:
mas em caso de duvida existe o Javadoc para esplicar o conceito

sergiotaborda wrote:
Se vc chamar de PaymentTitle alguem o vai contradizer ?

sergiotaborda wrote:
Mas se o cara tivesse dicidido no inicio

sergiotaborda wrote:pessoas que entender portugues

sergiotaborda wrote:as irão usar

sergiotaborda wrote:Isso é inaceitável. E essa é o vosso problema

sergiotaborda wrote:isso é uma limitação da equipe.

pelo menos a equipe sabe português...

sergiotaborda wrote:
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".

Ainda não entendi por que um alemão (nada contra os alemães) iria querer utilizar nossa API, sendo que ela gera boletos exclusivamente para os bancos brasileiros...

sergiotaborda wrote:
E a decisão parece ser apenas baseada na preguiça ou no desconhecimento. Isso que é triste.

é verdade... aliás, vou encerrar por aqui! Já são 15h00 e vou dar uma dormidinha!

This message was edited 4 times. Last update was at 28/05/2008 14:52:15

caueguerra wrote:

sergiotaborda wrote:
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.

bom que avisou...

E mesmo assim não valeu de nada...
Eu não me importo que se alguem se ofenda, isso é apenas um sinal da maturidade da pessoa, mas ficar dando uma de
ad hominem não deixo passar. Isso é ainda mais lamentável porque me obriga a usar do direito de resposta.

sergiotaborda wrote:
O problema de traduzir as palavras é irrelevante porque isso é uma limitação da equipe.

Muito gentis tuas palavras...

Foram realmente gentis. Poderia ter dito o que realmente eu acho sobre isso.
Traduzir é uma daquelas coisas que faz quem sabe, não quem pode.

sergiotaborda wrote:
Se vc chamar de PaymentTitle alguem o vai contradizer ?

Essa não entendi. Qual é o problema com essa parte em negrito ?

contradizer | v. tr. | v. int. | v. refl.

do Lat. contradicere

v. tr.,
dizer o contrário de;
contrariar;
contestar;
v. int.,
alegar o contrário;
v. refl.,
dizer o contrário do que se tinha afirmado.
(http://www.priberam.pt/dlpo/dlpo.aspx)

sergiotaborda wrote:as irão usar

Esta tb não entendi. irão : 3ª pess. plu. fut. ind. de ir (mesma fonte que antes)

sergiotaborda wrote:isso é uma limitação da equipe.

pelo menos a equipe sabe português...

Tenho minhas duvidas. Quando a pessoa se apega a erros de digitação e se confunde
com palavras que existem é dificil decidir se a equipa realmente sabe português.
Quando a pessoa grifa não estou tentando ofender ninguem no meu próprio texto e
mesmo assim desata num ataque ad hominem infundado é dificil aceitar que a pessoa entende português.

sergiotaborda wrote:
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".

Ainda não entendi por que um alemão (nada contra os alemães) iria querer utilizar nossa API, sendo que ela gera boletos exclusivamente para os bancos brasileiros...

lol... Bancos brasileiros ? O HSBC é brasileiro ? Até o bradesco é espanhol. O que vc quer dizer é "bancos que atuam no Brasil"
E porquê os alemães não pode usar uma API que emita boletos para bancos que atuam no brasil? Como perguntei antes: todos os sistemas usados no brasil são criados no brasil / por brasileiros ? Com certeza não. Vc sabe o que é outsourcing ? já ouviu falar da terceirização na India ?

Mas afinal porque me dou ao trabalho de chamar a atenção para o obvio quando nem sequer vou usar a API nem tenho nada a haver com Caelum ? Porque a Caelum não é o centro do mundo e o Stella não é a unica API com esse problema (vide JBoleto, BrazilUtils ) e o objetivo era discutir esse problema. Mas parece que ninguem consegue ver além do titulo do post...

Pelo menos tem todas as API feitas no brasil seguem a logica da gambiarra
https://genesis.dev.java.net/nonav/3.1/maven-site/pt-BR/index.html

Já é uma esperança.

Olá

Uma pena que o lançamento de uma API tão útil tenha chegado neste ponto meio belicoso. Já ficou claro aqui e no blog da caelum, os motivos das escolhas dos nomes. Em várias da aplicações que trabalhei encontrei grandes dificuldades para encontrar nomes para satisfazer a todos. Quem é que não passou por isto? E quem é que não tem aplicações com nomes estranho e até mesmo escritos erradamente?

A gente deveria para de discutir esta questão e focar nas questões técnicas da API

[]s
Luca

Perfeito Luca. Obrigado.

Luca wrote:A gente deveria para de discutir esta questão e focar nas questões técnicas da API

[]s
Luca

+1

Por exemplo, eu quero um exemplinho de repositories para adicionar no maven para usar os snapshots!

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 696 Offline

sergiotaborda wrote:Pelo menos nem todas as API feitas no brasil seguem a logica da gambiarra
https://genesis.dev.java.net/nonav/3.1/maven-site/pt-BR/index.html

Já é uma esperança.

Ficou difícil eu não me manifestar agora.

Sérgio, eu entendo seu ponto de vista e respeito. Porém, tudo é uma questão de domínio e público alvo. O genesis é um framework para auxiliar o desenvolvimento desktop. Esse é um conceito amplo e o público-alvo com certeza inclui pessoas de todas as nacionalidades.

Em compensação, o Stella foca em problemas do nosso país. Esse é um conceito restrito à realidade brasileira e o público-alvo é o desenvolvedor brasileiro. Eu diria que pena é não poder usar apenas nomes em português pra tudo nesse caso.

Eu acho que não podemos ser extremistas e usar de bom senso tendo isso em vista. O mesmo se dá com respeito ao design da API e as tecnologias usadas num projeto/produto: o genesis foi feito de um jeito muito mais "sofisticado" que as aplicações de clientes em que participei, onde pessoas de diferentes capacidades vão ter que interagir com o código. Da mesma forma, a JSR-310 tem um design ainda mais purista do que o genesis e uma API completamente diferente.

Por sinal, no sistema do cliente onde estou há 4 anos, usamos um padrão de nomenclatura muito parecido com o Stella, exceto que um pouquinho mais puxado para o português. Pronto, pode me fuzilar agora

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 696 Offline

Esqueci de contar um fato: já trabalhei em uma empresa onde as APIs eventualmente eram escritas em alemão - e eu tenho dificuldade de escrever corretamente o nome da empresa até hoje, por sinal

No caso deles, não acho que foi uma boa decisão, pois são uma multinacional, a API já foi criada nesse cenário, o domínio do software (praticamente) nada tem a ver com a cultura do país e com certeza o público-alvo principal não era alemão. Porém, se fosse algum framework/API ligada ao sistema tributário alemão, não veria problema nenhum nisso.

E detalhe: depois de dois dias perdido, consegui me virar. Então não vejo problemas.

Virtual Machine Man Membro desde: 18/03/2005 16:13:17 Mensagens: 696 Offline

thingol wrote:/** * @return Holen Sie sich die Meilensteine der Wert der Strichcode-Etikett auf den Preis. */ public double getBarcodeVonPreisschild () { return ...; }

Método que retorna double é perigoso em qualquer língua... :-)

thingol wrote:/** * @return Holen Sie sich die Meilensteine der Wert der Strichcode-Etikett auf den Preis. */ public double getBarcodeVonPreisschild () { return ...; }

O pior eh que o javadoc explica o que o getter faz... literalmente uma segunda descricao do getter = comentario nao tao util no meu ponto de vista :)

Virtual Machine Man Membro desde: 23/01/2008 11:14:35 Mensagens: 610 Offline

Luca wrote:Olá

Uma pena que o lançamento de uma API tão útil tenha chegado neste ponto meio belicoso. Já ficou claro aqui e no blog da caelum, os motivos das escolhas dos nomes. Em várias da aplicações que trabalhei encontrei grandes dificuldades para encontrar nomes para satisfazer a todos. Quem é que não passou por isto? E quem é que não tem aplicações com nomes estranho e até mesmo escritos erradamente?

A gente deveria para de discutir esta questão e focar nas questões técnicas da API

[]s
Luca

Quando você for pra Nova York, e visitar uma loja e comprar algumas roupas, paga em Real, se o gringo reclamar, diz que o Dollar no Brasil os seus clientes não aceitam.