Author: aldo.vadillo Date: Sun Aug 12 18:07:00 2007 New Revision: 965 Log: Traducidos párrafos 7 - 16, capítulo 6
Modified: trunk/es/ch06.xml Modified: trunk/es/ch06.xml ============================================================================== --- trunk/es/ch06.xml (original) +++ trunk/es/ch06.xml Sun Aug 12 18:07:00 2007 @@ -76,74 +76,73 @@ historia:</para> <blockquote> - <para>Back in 1993, I was working for the Free Software Foundation, - and we were beta-testing version 19 of GNU Emacs. We'd make a beta - release every week or so, and people would try it out and send us - bug reports. There was this one guy whom none of us had met in - person but who did great work: his bug reports were always clear and - led us straight to the problem, and when he provided a fix himself, - it was almost always right. He was top-notch.</para> - - <para>Now, before the FSF can use code written by someone else, we - have them do some legal paperwork to assign their copyright interest - to that code to the FSF. Just taking code from complete strangers - and dropping it in is a recipe for legal disaster.</para> - - <para>So I emailed the guy the forms, saying, "Here's some paperwork - we need, here's what it means, you sign this one, have your employer - sign that one, and then we can start putting in your fixes. Thanks - very much."</para> - - <para>He sent me back a message saying, "I don't have an - employer."</para> - - <para>So I said, "Okay, that's fine, just have your university sign - it and send it back."</para> - - <para>After a bit, he wrote me back again, and said, "Well, - actually... I'm thirteen years old and I live with my - parents."</para> + <para>Por el año 1993 trabajaba para la Fundación de Software Libre, + y estábamos llevando a cabo el beta-testing de la versión 19 de GNU Emacs. Haríamos una + publicación beta más o menos cada semana, y la gente la probaría y nos enviaría + informes de error. Había un chico que ninguno de nosotros conocía en + persona pero que hizo un gran trabajo: sus informes de error siempre fueron claros y + nos enfocaba hacia el problema y, cuando nos proporcionaba una corrección, + casi siempre tenía razón. Era un fuera de serie.</para> + + <para>Ahora, antes que la FSF pueda utilizar código escrito por alguien, hay que + realizar un papeleo legal para que el interés de esa persona hacia el copyright + del código pase a la FSF. Simplemente tomando el código de completos extraños + and dropping it in es una receta para el desastre legal.</para> + + <para>Por lo que le envié un correo al chico con los formularios diciéndole "Te envío algo de papeleo + que necesitamos, esto es lo que significa, firmas este, haces que quien te tiene contratado + firme este otro y, entonces podemos comenzar a utilizar tus correcciones. Muchas + gracias."</para> + + <para>Me envió un mensaje de vuelta diciendo: "No trabajo para + nadie."</para> + + <para>Por lo que le dije: "Bien, eso está bien, simplemente haz que firme tu universidad + y envíamelo de vuelta."</para> + + <para>Después de un poco, me escribió de nuevo y me dijo: "Verás, + realmente... tengo trece años y vivo con mis padres."</para> </blockquote> -<para>Because that kid didn't write like a thirteen-year-old, no one -knew that's what he was. Following are some ways to make your writing -give a good impression too.</para> +<para>Debido a que ese chico no escribía como si tuviera trece años nadie +supuso que los tuviera. A continuación se exponen también algunas cosas que +conseguirán además que tu escritura de una buena impresión.</para> <!-- ======================== subsection ============================== --> <sect2 id="structure-and-formatting"> -<title>Structure and Formatting</title> +<title>Estructura y formato</title> -<para>Don't fall into the trap of writing everything as though it were -a cell phone text message. Write in complete sentences, capitalizing -the first word of each sentence, and use paragraph breaks where -needed. This is most important in emails and other composed writings. -In IRC or similarly ephemeral forums, it's generally okay to leave out -capitalization, use compressed forms of common expressions, etc. Just -don't carry those habits over into more formal, persistent forums. -Emails, documentation, bug reports, and other pieces of writing that -are intended to have a permanent life should be written using standard -grammar and spelling, and have a coherent narrative structure. This -is not because there's anything inherently good about following -arbitrary rules, but rather that these rules are -<emphasis>not</emphasis> arbitrary: they evolved into their present -forms because they make text more readable, and you should adhere to -them for that reason. Readability is desirable not only because it -means more people will understand what you write, but because it makes -you look like the sort of person who takes the time to communicate -clearly: that is, someone worth paying attention to.</para> - -<para>For email in particular, experienced open source developers have -settled on certain conventions:</para> - -<para>Send plain text mails only, not HTML, RichText, or other formats -that might be opaque to text-only mail readers. Format your lines to -be around 72 columns long. Don't exceed 80 columns, which has become -the <foreignphrase>de facto</foreignphrase> standard terminal width -(that is, some people may use wider terminals, but no one uses a -narrower one). By making your lines a little -<emphasis>less</emphasis> than 80 columns, you leave room for a few -levels of quoting characters to be added in others' replies without -forcing a rewrapping of your text.</para> +<para>No caigas en la trampa de escribir todo como si fuera +un mensaje de teléfono móvil. Escribe frases completas, poniendo en mayúsculas +la primera palabra de cada frase, y usando separaciones de párrafo donde +sea necesario. Esto es lo más importante en correos electrónicos y otras composiciones. +En el IRC u otros foros efímeros similares, generalmente es correcto dejar de poner +mayúsculas, utilizar formas comprimidas o expresiones comunes, etc. Simplemente +no lleves esos hábitos a foros más formales o persistentes. +Correos electrónicos, documentación, informes de error y otras piezas de escritura que +suelen tener una larga vida deberían escribirse usando una gramática y +una spelling estándar, y tener una estructura narrativa coherente. Esto +no se debe a que haya algo inherentemente bueno siguiendo +reglas arbitrarias, sino a que estas reglas +<emphasis>no</emphasis> son arbitrarias: evolucionan en las formas presentes +ya que hacen que el texto sea más leíble y, por esa razón, deberías +seguirlas. La legibilidad no sólo es deseable para que +la mayoría de gente entienda lo que escribes, sino porque hace que +que parezcas la clase de persona que se toma su tiempo en comunicarse de una forma +clara: es decir, alguien a quien vale la pena prestar atención.</para> + +<para>En particular, para correos electrónicos, desarrolladores experimientados de open source +han decidido ciertas convenciones:</para> + +<para>Envía correos solo de texto plano, no en HTML, texto enriquecido u otros formatos +ya que podrían no ser leidos por lectores que leen sólo texto plano. Formatea las líneas para +que estén sobre las 72 columnas de largo. No excedas las 80 columnas, que ha sido +<foreignphrase>de facto</foreignphrase> el ancho estándar del terminal +(es decir, hay gente que utiliza terminales más anchos, pero nadie utiliza +terminales no más estrechos). Al hacer las líneas un poco +<emphasis>menores</emphasis> de 80 columnas da cabida a unos cuantos +niveles de caracteres de citado para ser añadidos en otras respuestas sin +forzar un estrechamiento de tu texto.</para> <para><emphasis>Use real line breaks.</emphasis> Some mailers do a kind of fake line wrapping, whereby when you're composing an email, _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
