On 8/28/07, Ari Constancio <[EMAIL PROTECTED]> wrote: > Discordo absolutamente da tradução de patch como 'remendo' - este é um > dos vários casos em que a tradução não faz sentido, desvirtuando o > significado original. Havendo tradução, seria mais correctamente uma > 'diferença', já que o patch é um simples diff.
Carlos, Continuo a achar que não faz sentido traduzir 'patch' - o termo 'diferença' obriga sempre a uma explicação do contexto e é provavelmente irreconhecível a quem conhece o mundo open source. 'patch' é preferível. Ari Constâncio On 8/28/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Author: cafonso > Date: Tue Aug 28 15:07:57 2007 > New Revision: 1123 > > Log: > Chap 05 Minor editing subt remendo by diferença > > Modified: > trunk/pt-pt/ch05.xml > > Modified: trunk/pt-pt/ch05.xml > ============================================================================== > --- trunk/pt-pt/ch05.xml (original) > +++ trunk/pt-pt/ch05.xml Tue Aug 28 15:07:57 2007 > @@ -268,7 +268,7 @@ > acesso de submissão de alguém que tenha saído (ver > <xref linkend="money-vs-love"/> adiante neste capítulo), assim se > o novo programador não tiver já acesso de submissão, terá que > -submeter remendos até o ter. Mas o acesso de submissão é só a > +submeter as diferenças até o ter. Mas o acesso de submissão é só a > manifestação mais mensurável dessa perca de influência. Um programador > de longo prazo também conhece todos os argumentos antigos que foram > apresentados e reapresentados nas listas de discussão. Um programador > @@ -300,15 +300,15 @@ > no Subversion, sentamos-nos com ele e escolhemos uns quantos erros > em aberto para que essa pessoa possa ter um cheirinho. Discutiremos > os aspectos técnicos gerais das soluções e depois escolheremos pelo > -menos um programador experiente para (publicamente) rever o remendo > +menos um programador experiente para (publicamente) rever as diferenças > que o novo programador irá (também publicamente) colocar. Normalmente > -não iremos sequer olhar para o remendo antes da lista principal de > +não iremos sequer olhar para a diferença antes da lista principal de > desenvolvimento o ver, embora o possamos fazer se houver alguma > razão para isso. O importante é que o novo programador passe pelo > processo de revisão pública, aprendendo as fundações do código e > em simultâneo se habitue a receber críticas de completos estranhos. > Mas tentamos coordenar os tempos de modo a que as nossas próprias > -críticas apareçam imediatamente após a colocação do remendo. Assim a > +críticas apareçam imediatamente após a colocação da diferença. Assim a > primeira crítica que a lista vê é a nossa, o que pode ajudar a estabelecer > o tom para as críticas dos restantes. Também contribui para a ideia > de que esta nova pessoa é para ser levada a sério: se os outros virem > @@ -318,7 +318,7 @@ > indicativo de investimento a longo prazo. Isso pode levar a que fiquem > mais favoráveis em relação ao programador, pelo menos até ao ponto > de gastarem um pouco mais de tempo em responder às questões e > -criticar remendos.</para> > +criticar diferenças.</para> > > </sect1> > > @@ -333,7 +333,7 @@ > mas não é disso que trata este livro). Em vez disso deve-se > a que os indivíduos são o único tipo de entidade para o qual os > projectos open source estão preparados estruturalmente. Um > -contribuinte individual, tem discussões, submete remendos, > +contribuinte individual, tem discussões, submete diferenças, > adquire credibilidade, vota, etc... Uma empresa não o pode > fazer.</para> > > > _______________________________________________ > Producingoss-translators mailing list > [email protected] > http://www.red-bean.com/mailman/listinfo/producingoss-translators > _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
