Re: [GNU-traductores] Traducción de /p/funding-art-vs-funding-software.html

[Dora Scilipoti]

On 20/04/2016 12:18, Javier Fdez. Retenaga wrote:
> 
> Vamos a terminar con la revisión de Ondiz:
> 
> 
>> Consider, for example, the free program GNU Emacs. Our records of
>> contributions to the code of GNU Emacs are incomplete in the period
>> before we started using version control—before that we have only
>> the change logs.  But let's imagine we still had every version and could
>> determine precisely what code contribution is due to each of the hundreds
>> of contributors. We'd still be stuck.
>>
>> Consideremos, por ejemplo, el programa libre GNU Emacs. Nuestros registros
>> de contribuciones al código de GNU Emacs son incompletos en el periodo
>> anterior a que empezásemos a usar control del versiones, antes de eso
>> solo tenemos registros de cambios. Pero imaginemos que tuviéramos cada
>> versión y pudiéramos determinar con precisión qué contribución
>> al código se debe a cada uno de los cientos de colaboradores. Aún
>> estaríamos atascados.
> 
> - Nuestros registros de contribuciones al código de GNU Emacs son
> incompletos en el periodo anterior a que empezásemos a usar control del
> versiones, antes de eso solo tenemos registros de cambios. 
> + Nuestros registros de contribuciones al código de GNU Emacs del
> periodo anterior a que empezásemos a usar control del versiones son
> incompletos, de ese periodo solo disponemos de los registros de cambios.
>
> - Aún estaríamos atascados.
> - Seguiríamos atascados.

+ Consideremos, por ejemplo, el programa libre GNU Emacs. Nuestros
registros de contribuciones al código de GNU Emacs están incompletos para
el periodo en que aún no utilizábamos un sistema de control de versiones,
de ese periodo solo disponemos del histórico de cambios
(<cite>changelogs</cite>). Pero supongamos que tuviéramos todas las
versiones y pudiéramos determinar con precisión cuáles fueron las
contribuciones al código de cada uno de los cientos de colaboradores. Aun
así seguiríamos atascados.


>> If we wanted to give credit in proportion to lines of code (or should
>> it be characters?), then it would be straightforward, once we decide
>> how to handle a line that was written by A and then changed by B. But
>> that assumes each line as important as every other line. I am sure that
>> is wrong&mdash;some pieces of the code do more important jobs and others
>> less; some code is harder to write and other code is easier. But I see no
>> way to quantify these distinctions, and the developers could argue about
>> them forever. I might deserve some additional credit for having initially
>> written the program, and certain others might deserve additional credit
>> for having initially written certain later important additions, but I
>> see no objective way to decide how much. I can't propose a justifiable
>> rule for dividing up the popularity credit of a program like GNU Emacs.
>>
>> Si quisiéramos dar crédito en proporción a las líneas de código
>> (¿o debería ser según los caracteres?), entonces sería claro, una
>> vez que decidiéramos cómo apañarnos con una línea que escribió A
>> y luego cambió B. Pero así asumimos que cada línea de código es tan
>> importante como todas las demás.  Estoy seguro de que eso es erróneo,
>> algunas líneas de código realizan tareas más importantes y otras
>> menos, hay código que es más difícil de escribir que otro. Pero no
>> veo una manera de cuantificar estas diferencias y los desarrolladores
>> podrían discutir sobre ellas eternamente. Puede que yo merezca algo
>> de crédito adicional por haber escrito inicialmente el programa y que
>> ciertas personas merezcan crédito adicional por haber escrito ciertas
>> ampliaciones posteriores, pero no veo una forma objetiva de decidir
>> cuánto. No puedo proponer una regla justificable para dividir la
>> popularidad de un programa como GNU Emacs.
> 
> + Si quisiéramos reconocer el trabajo en proporción a las líneas de
> código (¿o debería ser según los caracteres?), entonces estaría claro,
> una vez que decidiéramos qué hacer con una línea que escribió A y luego
> cambió B. Pero de ese modo se da por hecho que cada línea de código es
> tan importante como cualquier otra. No me cabe duda de de que eso es un
> error: unas líneas de código realizan tareas más importantes y otras
> menos; hay código que es más difícil de escribir y otros que es más
> sencillo. Pero no veo la manera de cuantificar esas diferencias, y los
> desarrolladores podrían discutir sobre ellas eternamente. Es posible que
> yo merezca algún reconocimiento adicional por haber escrito el programa
> inicial, y que algunos otros merezcan un reconocimiento adicional por
> haber comenzado a escribir ciertos añadidos que luego fueron
> importantes, pero no veo una forma objetiva de determinar cuánto. Me es
> imposible proponer una regla justificada para repartir el reconocimiento
> por la popularidad de un programa como GNU Emacs.

- Si quisiéramos reconocer el trabajo en proporción a las líneas de código
+ Si quisiéramos reconocer el trabajo de cada uno en proporción a las
líneas de código que aportó


- No me cabe duda de de que eso es un error: unas líneas de código realizan
tareas más importantes y otras menos; hay código que es más difícil de
escribir y otros que es más sencillo.

+ No me cabe duda de que eso es un error, pues algunas líneas de código
realizan tareas muy importantes y otras menos, y hay códigos que son muy
difíciles de escribir y otros más sencillos.

- podrían discutir sobre ellas eternamente.
+ podrían discutir sobre ello eternamente.

- una forma objetiva de determinar cuánto.
+ una forma objetiva de cuantificarlo.

# Aunque parezca repetición, creo que queda mejor.

- regla justificada
+ plausible

# También podría ser "lógica".


>> As for asking all the contributors to negotiate an agreement, we can't
>> even try. There have been hundreds of contributors, and we could not
>> find them all today. They contributed across a span of 26 years, and
>> never at any time did all those people decide to work together.
>>
>> En cuanto a pedir a todos los colaboradores que negocien un acuerdo,
>> ni siquiera podemos intentarlo. Ha habido cientos de colaboradores y no
>> podríamos localizarlos a todos hoy en día. Contribuyeron durante un
>> periodo de 26 años y nunca en todo ese tiempo decidieron trabajar juntos.
>>
> 
> + En cuanto a pedir a todos los colaboradores que lleguen a un acuerdo,
> ni siquiera podemos intentarlo. Ha habido cientos de colaboradores y a
> día de hoy no podríamos localizarlos a todos. Contribuyeron a lo largo
> de 26 años y nunca en todo ese tiempo decidieron trabajar juntos.

- y nunca en todo ese tiempo decidieron trabajar juntos.
+ y en todo ese tiempo nunca decidieron trabajar juntos.

>> We might not even know the names of all the authors. If some code
>> was donated by companies, we did not need to ask which persons wrote
>> that code.
>>
>> Es posible que ni siquiera conozcamos los nombres de todos los autores. Si
>> parte del código lo donaron empresas, no necesitábamos preguntar quién
>> escribió ese código.
> 
> + Es posible que ni siquiera conozcamos el nombre de todos los autores.
> Si una empresa donaba parte del código, no había necesidad de preguntar
> qué personas lo habían escrito.

- qué personas lo habían escrito.
+ quiénes lo habían escrito.

>> Then what about the forked or modified variants of GNU Emacs? Each one
>> is an additional case, equally complex but different. How much of the
>> credit for such a variant should go to those who worked on that variant,
>> and how much to the original authors of the code they got from other
>> GNU Emacs versions, other programs, and so on?
>>
>> Entonces, ¿qué ocurre con los forks o las variantes modificadas
>> de GNU Emacs? Cada una es un caso adicional, igualmente complejo
>> pero diferente. ¿Cuánta parte del crédito debe ir a parar a los que
>> trabajaron en la variante y cuánto a los autores originales del código
>> que obtuvieron de otras versiones de GNU Emacs, otros programas y así?
> 
> - forks
> + <em>forks</em>
> 
> - Cada una es
> + Cada una representa
> 
> - ¿Qué parte de reconocimiento por esa variante les corresponde a los
> que trabajaron en la variante y cuánto a los autores originales del
> código, tomado de otras versiones de GNU Emacs, de otros programas,
> etc.?


+ ¿Qué ocurre entonces con las bifurcaciones o las variantes modificadas de
GNU Emacs? Cada una representa un caso nuevo, igualmente complejo pero
direfente. ¿Cuánto reconocimiento por esa variante les corresponde a los
que trabajaron en ella y cuánto a los autores originales del código que
tomaron de otras versiones de GNU Emacs, de otros programas, etc.?


>> The conclusion is that there is no way we could come up with a division
>> of the credit for GNU Emacs and justify it as anything but arbitrary. But
>> Emacs is not a special case; it is a typical example. The same problems
>> would arise for many important free programs, and other free works such
>> as Wikipedia pages.
>>
>> La conclusión es que no hay manera de que podamos conseguir una división
>> del crédito de GNU Emacs y justificar que no es arbitraria. Pero Emacs no
>> es un caso especial, es un ejemplo típico. El mismo problema surgiría
>> en muchos programas libres importantes y en otras obras libres como las
>> páginas de la Wikipedia.
> 
> + La conclusión es que no hay manera de que podamos alcanzar un reparto
> del reconocimiento por GNU Emacs que no sea arbitrario. Pero Emacs no
> es un caso especial, es un ejemplo corriente. El mismo problema se
> presentaría con muchos importantes programas libres y en otras obras
> libres, como las páginas de la Wikipedia.

- y en otras obras libres,
+ y otras obras libres,

>> These problems are the reasons I don't propose using those two funding
>> systems in fields such as software, encyclopedias or education, where
>> all works ought to be free.
>>
>> Estos problemas son la razón por la que no propongo usar esos sistemas
>> de financiación en campos como el software, las enciclopedias o la
>> educación, donde todas las obras deberían ser libres.

- deberían ser libres.
+ deben ser libres.


>> What makes sense for these areas is to ask people to donate to
>> <em>projects</em> for the work <em>they propose to do</em>. That system
>> is simple.
>>
>> Lo que tiene sentido para esas áreas es pedir a las personas que donen
>> dinero a <em>proyectos</em> para la obra <em>que proponen hacer</em>. Ese
>> sistema es simple.
> 
> + En esas áreas lo que tiene sentido es pedir a la gente que done
> dinero a los <em>proyectos</em> destinados a realizar la obra <em>que
> ellos proponen</em>. Ese sistema es muy simple.

- que ellos proponen
+ que proponen

>> The Free Software Foundation asks for donations in two ways. We ask for
>> <a href=\"https://my.fsf.org/donate/\";> general donations to support the
>> foundation's work</a>, and we invite <a href=\"https://my.fsf.org/donate
>> /directed-donations\"> targeted donations for certain specific
>> projects</a>.  Other free software organizations do this too.
>>
>> La Free Software Foundation pide donaciones de dos maneras. Pedimos
>> <a href=\"https://my.fsf.org/donate/\";> donaciones generales
>> para financiar el trabajo de la fundación</a> y solicitamos <a
>> href=\"https://my.fsf.org/donate /directed-donations\"> donaciones
>> dirigidas a proyectos específicos</a>. Otras organizaciones de software
>> libre hacen lo mismo.
> 
> + La Free Software Foundation pide donaciones de dos tipos. Pedimos <a
> href=\"https://my.fsf.org/donate/\";>donaciones genéricas para financiar
> el trabajo de la fundación</a> y <a href=
> \"https://my.fsf.org/donate /directed-donations\">donaciones
> específicas para proyectos concretos</a>. Otras organizaciones de
> software libre también lo hacen así.



-- 
Dora Scilipoti
GNU Education Team
www.gnu.org/education