programming-guidelines: comparison programming-guidelines.xml

equal deleted inserted replaced

-:4ca4c0227161
+:4e44e6123b42
 <article class="techreport" id="index" lang="es">
 <articleinfo>
-<title>Gu�a de programaci�n de GNOME</title>
+<title>Guía de programación de GNOME</title>
 <authorgroup>
 <author>
 	<firstname>Federico</firstname>
 	<surname>Mena Quintero</surname>
 	</affiliation>
 </author>
 <othercredit>
 	<firstname>Germ&aacute;n</firstname>
 	<surname>Po&oacute; Caama&ntilde;o</surname>
-	<contrib>Traducci�n al espa�ol</contrib>
+	<contrib>Traducción al español</contrib>
 	<affiliation>
 	  <address>
 	    <email>gpoo@ubiobio.cl</email>
 	  </address>
 	</affiliation>
 </othercredit>
 <othercredit>
 	<firstname>Lucas</firstname>
 	<surname>Vieites Fari&ntilde;a</surname>
-	<contrib>Revisi�n de la traducci�n al espa�ol </contrib>
+	<contrib>Revisión de la traducción al español </contrib>
 	<affiliation>
 	  <address>
 	    <email>lucas@asixinformatica.com</email>
 	  </address>
 	</affiliation>
 </othercredit>
 <othercredit>
 	<firstname>Sergio</firstname>
 	<surname>Villar Senin</surname>
-	<contrib>Revisi�n de la traducci�n al espa�ol  </contrib>
+	<contrib>Revisión de la traducción al español  </contrib>
 	<affiliation>
 	  <address>
 	    <email>svillar@igalia.com</email>
 	  </address>
 	</affiliation>
 <year>2000</year>
 <holder>The Free Software Foundation</holder>
 </copyright>
 <copyright>
 <year>2004&mdash;2006</year>
-<holder>GNOME Foundation, respecto de la versi�n en espa�ol.</holder>
+<holder>GNOME Foundation, respecto de la versión en español.</holder>
 </copyright>
 <abstract>
 <para>
-	Este art�culo contiene var�as gu�as y sugerencias para los
+	Este artículo contiene varías guías y sugerencias para los
-	programadores de GNOME, as� como ciertas pol�ticas que
+	programadores de GNOME, así como ciertas políticas que
-	deber�an seguirse cuando se escriben programas para GNOME.
+	deberían seguirse cuando se escriben programas para GNOME.
 	Es un intento para que los programadores puedan aprender
-	acerca del proceso de desarrollo de GNOME y su filosof�a.
+	acerca del proceso de desarrollo de GNOME y su filosofía.
-	GNOME es un esfuerzo de equipo, as� que ser� �til para
+	GNOME es un esfuerzo de equipo, así que será útil para
-	que los programadores sepan �la forma de hacer la
+	que los programadores sepan «la forma de hacer la
-	cosas�.
+	cosas».
 </para>
 </abstract>
 </articleinfo>
 <!-- Introduction -->
 <sect1 id="intro">
-<title>Introducci�n</title>
+<title>Introducción</title>
 <para>
-	  GTK+, la biblioteca de interfaz de usuario b�sica de GNOME, nos
+	  GTK+, la biblioteca de interfaz de usuario básica de GNOME, nos
-	  ha ense�ado algunas lecciones importantes en el dise�o de software.
+	  ha enseñado algunas lecciones importantes en el diseño de software.
-	  El c�digo de GTK+ es limpio, consistente, mantenible y tiene
+	  El código de GTK+ es limpio, consistente, mantenible y tiene
-	  sentido.  Tal c�digo no s�lo provoca placer al trabajar con el,
+	  sentido.  Tal código no sólo provoca placer al trabajar con el,
-	  sino que adem�s es un incentivo para las buenas pr�cticas de
+	  sino que además es un incentivo para las buenas prácticas de
-	  programaci�n para aquellos que quieran extenderlo y modificarlo.
+	  programación para aquellos que quieran extenderlo y modificarlo.
 </para>
 <para>
-	  En este art�culo intentamos presentar algunas sugerencias y
+	  En este artículo intentamos presentar algunas sugerencias y
-	  lineamientos que deber�as tener en cuenta cuando escribas c�digo
+	  lineamientos que deberías tener en cuenta cuando escribas código
-	  para el proyecto GNOME.  Presentamos algunas de las pol�ticas
+	  para el proyecto GNOME.  Presentamos algunas de las políticas
-	  que deben seguirse cuando se modifica el c�digo de otras
+	  que deben seguirse cuando se modifica el código de otras
-	  personas, usando el repositorio CVS y asegur�ndose de que el
+	  personas, usando el repositorio CVS y asegurándose de que el
-	  c�digo se ajusta para ser inclu�do en GNOME. Tambi�n
+	  código se ajusta para ser incluído en GNOME. También
-	  presentamos informaci�n que ser� �til para los mantenedores
+	  presentamos información que será útil para los mantenedores
 	  de paquetes.
 </para>
 <para>
-	  Adem�s de este documento, aseg�rate de leer los Est�ndares de
+	  Además de este documento, asegúrate de leer los Estándares de
-	  Programaci�n de GNU.  Estos se encuentran disponibles en el
+	  Programación de GNU.  Estos se encuentran disponibles en el
-	  nodo info <filename>(Standards)</filename> en la documentaci�n
+	  nodo info <filename>(Standards)</filename> en la documentación
-	  est�ndar de GNU.
+	  estándar de GNU.
 </para>
 </sect1>
 <!-- The Importance of Writing Good Code -->
 <sect1 id="good-code">
-<title>La importancia de escribir buen c�digo</title>
+<title>La importancia de escribir buen código</title>
 <para>
 	  GNOME es un proyecto de software libre muy ambicioso y, como tal,
-	  est� compuesto por muchos paquetes de software que son m�s o menos
+	  está compuesto por muchos paquetes de software que son más o menos
 	  independientes el uno del otro.  Mucho del trabajo en GNOME lo
 	  realizan voluntarios; programadores que vienen y se van
-	  en cualquier momento y que ser�n capaces de dedicar
+	  en cualquier momento y que serán capaces de dedicar
 	  diferentes cantidades de tiempo al proyecto GNOME.
 	  Muchas personas trabajan en software libre en su tiempo libre o
-	  como un pasatiempo, as�, si sus responsabilidades del &lsquo;mundo
+	  como un pasatiempo, así, si sus responsabilidades del &lsquo;mundo
-	  real&rsquo; cambian, se ver� reflejado en la cantidad de trabajo que
+	  real&rsquo; cambian, se verá reflejado en la cantidad de trabajo que
-	  dedicar�n a proyectos de software libre.
+	  dedicarán a proyectos de software libre.
 </para>
 <para>
 	  Se tarda mucho tiempo en escribir software y supone una
 	  gran cantidad de trabajo. Es por esto que muchos
 	  de los voluntarios de tiempo parcial no pueden comenzar
-	  grandes proyectos por s� mismos; es mucho m�s f�cil y
+	  grandes proyectos por sí mismos; es mucho más fácil y
 	  gratificante contribuir a proyectos existentes, puesto que
 	  los resultados son inmediatamente visibles y usables.
 </para>
 <para>
 	  Teniendo esto en cuenta y el hecho que los programadores de
 	  software libre tiene recursos escasos, concluimos que
 	  para los proyectos existentes es muy importante facilitar,
 	  tanto como sea posible, que otras personas puedan contribuir.
-	  Una forma de hacerlo es asegur�ndose de que los programas
+	  Una forma de hacerlo es asegurándose de que los programas
-	  sean f�ciles de leer, entender y modificar.
+	  sean fáciles de leer, entender y modificar.
 </para>
 <para>
-	  El c�digo desordenado es dif�cil de leer y las personas pueden
+	  El código desordenado es difícil de leer y las personas pueden
-	  perder inter�s si no son capaces de descifrar lo que el c�digo
+	  perder interés si no son capaces de descifrar lo que el código
-	  intenta hacer.  Adem�s, es importante que los programadores sean
+	  intenta hacer.  Además, es importante que los programadores sean
-	  capaces de entender el c�digo r�pidamente, y as� poder comenzar
+	  capaces de entender el código rápidamente, y así poder comenzar
-	  a contribuir reparando fallos y extendi�ndolo en un per�odo breve
+	  a contribuir reparando fallos y extendiéndolo en un período breve
-	  de tiempo.  El c�digo fuente es una forma de comunicaci�n, y as�
+	  de tiempo.  El código fuente es una forma de comunicación, y así
-	  como a alguien podr�a no querer leer una novela con errores
+	  como a alguien podría no querer leer una novela con errores
-	  ortogr�ficos y mala puntuaci�n, los programadores deben intentar
+	  ortográficos y mala puntuación, los programadores deben intentar
-	  escribir buen c�digo de tal forma que sea f�cil de entender y
+	  escribir buen código de tal forma que sea fácil de entender y
 	  modificar por otros.
 </para>
 <para>
 	  Existen algunas cualidades que son importantes en un buen
-	  c�digo y por qu� son importantes para los desarrolladores
+	  código y por qué son importantes para los desarrolladores
 	  de software libre:
 <variablelist>
 	<varlistentry>
 	  <term>Limpieza</term>
 	  <listitem>
 	    <para>
-		  Un c�digo limpio es f�cil de leer; permite a las
+		  Un código limpio es fácil de leer; permite a las
-		  personas leerlo con un m�nimo esfuerzo y as� pueden
+		  personas leerlo con un mínimo esfuerzo y así pueden
-		  entenderlo m�s f�cilmente.
+		  entenderlo más fácilmente.
 	    </para>
 	  </listitem>
 	</varlistentry>
 	<varlistentry>
 	  <term>Consistencia</term>
 	  <listitem>
 	    <para>
-		  El c�digo consistente permite m�s f�cilmente que las
+		  El código consistente permite más fácilmente que las
 		  personas entiendan como funciona el programa; cuando se
-		  lee c�digo consistente, subconcientemente uno se forma
+		  lee código consistente, subconcientemente uno se forma
-		  un n�mero de supuestos y expectativas acerca del
+		  un número de supuestos y expectativas acerca del
-		  funcionamiento del c�digo, de esta forma es m�s f�cil
+		  funcionamiento del código, de esta forma es más fácil
 		  y seguro realizarle modificaciones.
 	    </para>
 	  </listitem>
 	</varlistentry>
 	<varlistentry>
 	  <term>Extensibilidad</term>
 	  <listitem>
 	    <para>
-		  El c�digo de prop�sito general es m�s f�cil de reutilizar
+		  El código de propósito general es más fácil de reutilizar
-		  y modificar que el c�digo demasiado espec�fico con muchos
+		  y modificar que el código demasiado específico con muchos
-		  supuestos escritos directamente en el c�digo (hardcoded).
+		  supuestos escritos directamente en el código (hardcoded).
-		  Cuando alguien desea agregar una nueva caracter�stica
+		  Cuando alguien desea agregar una nueva característica
-		  a un programa, obviamente ser� m�s f�cil hacerlo si el
+		  a un programa, obviamente será más fácil hacerlo si el
-		  c�digo fue dise�ado para ser extensible desde el inicio.
+		  código fue diseñado para ser extensible desde el inicio.
-		  El c�digo que no fue escrito de esta forma har� que las
+		  El código que no fue escrito de esta forma hará que las
 		  personas deban implementar hacks muy feos para poder
-		  a�adir caracter�sticas.
+		  añadir características.
 	    </para>
 	  </listitem>
 	</varlistentry>
 	<varlistentry>
-	  <term>Correcci�n</term>
+	  <term>Corrección</term>
 	  <listitem>
 	    <para>
-		  Finalmente, el c�digo dise�ado debe ser correcto para
+		  Finalmente, el código diseñado debe ser correcto para
-		  que las personas pierdan menos tiempo preocup�ndose de
+		  que las personas pierdan menos tiempo preocupándose de
 		  los errores y se ocupen  en extender las
-		  caracter�sticas de un programa.  Los usuarios tambi�n
+		  características de un programa.  Los usuarios también
-		  apreciar�n un c�digo correcto, ya que a nadie le gusta
+		  apreciarán un código correcto, ya que a nadie le gusta
 		  que un programa se caiga.
 	    </para>
 	  </listitem>
 	</varlistentry>
 </variablelist>
 </para>
 <para>
 	  En resumen, los programadores a menudo contribuyen en
-	  su tiempo libre a proyectos de software libre, y a�n quienes
+	  su tiempo libre a proyectos de software libre, y aún quienes
 	  contribuyen de forma regular pueden detenerse en cualquier
-	  instante del tiempo, as� que es muy importante que el c�digo
+	  instante del tiempo, así que es muy importante que el código
 	  sea bueno y les permita modificarlo facilmente.  El resultado
-	  final ser� un mejor software al que los programadores
+	  final será un mejor software al que los programadores
-	  querr�n extender.
+	  querrán extender.
 </para>
 </sect1>
 <!-- Coding Style -->
 <sect1 id="code-style">
-<title>Estilo de programaci�n</title>
+<title>Estilo de programación</title>
 <para>
-&lsquo;El estilo de programaci�n&rsquo; se refiere a la forma en
+&lsquo;El estilo de programación&rsquo; se refiere a la forma en
-	  que se da formato al c�digo fuente.  Para C, esto involucra
+	  que se da formato al código fuente.  Para C, esto involucra
-	  la forma en que se ubican las llaves, se indenta el c�digo y
+	  la forma en que se ubican las llaves, se indenta el código y
-	  se utilizan los par�ntesis.  GNOME tiene una mezcla de estilos
+	  se utilizan los paréntesis.  GNOME tiene una mezcla de estilos
-	  de programaci�n y no se obliga el uso de ninguno de ellos.  Lo m�s
+	  de programación y no se obliga el uso de ninguno de ellos.  Lo más
-	  importante es que el c�digo sea consistente dentro de un programa
+	  importante es que el código sea consistente dentro de un programa
-	  o una biblioteca &mdash; el c�digo con un formato desordenado
+	  o una biblioteca &mdash; el código con un formato desordenado
-	  no es aceptable debido a que es dif�cil de leer.
+	  no es aceptable debido a que es difícil de leer.
 </para>
 <para>
 	  Cuando escribas un nuevo programa o biblioteca, sigue un
-	  estilo consistente de ubicaci�n de llaves y de indentaci�n.
+	  estilo consistente de ubicación de llaves y de indentación.
 	  Si no tienes ninguna preferencia personal de estilo,
-	  recomendamos el estilo de programaci�n del n�cleo de Linux o
+	  recomendamos el estilo de programación del núcleo de Linux o
-	  el estilo de programaci�n de GNU.
+	  el estilo de programación de GNU.
 </para>
 <para>
 	  Lee el nodo de info <filename>(Standards)Writing C</filename>
-	  en la documentaci�n de GNU. Luego, obt�n el c�digo fuente
+	  en la documentación de GNU. Luego, obtén el código fuente
 	  de Linux y lee el archivo
 	  <filename>linux/Documentation/CodingStyle</filename>, e
-	  ignora los chistes de Linus.  Estos dos documentos te dar�n
+	  ignora los chistes de Linus.  Estos dos documentos te darán
-	  una buena idea de nuestras recomendaciones para el c�digo de
+	  una buena idea de nuestras recomendaciones para el código de
 	  GNOME.
 </para>
 <!-- Indentation Style -->
 <sect2 id="indent">
-<title>Estilo de indentaci�n</title>
+<title>Estilo de indentación</title>
 <para>
-		Para el c�digo del n�cleo de GNOME preferimos el estilo
+		Para el código del núcleo de GNOME preferimos el estilo
-		de indentaci�n del n�cleo de Linux.  Usa tabuladores
+		de indentación del núcleo de Linux.  Usa tabuladores
-		de 8 espacios para la indentaci�n.
+		de 8 espacios para la indentación.
 </para>
 <para>
-		Usar tabuladores de 8 espacios para indentaci�n proporciona
+		Usar tabuladores de 8 espacios para indentación proporciona
-		un n�mero de beneficios.  Permite que el c�digo sea m�s
+		un número de beneficios.  Permite que el código sea más
-		f�cil de leer, ya que la indentaci�n se marca claramente.
+		fácil de leer, ya que la indentación se marca claramente.
-		Tambi�n ayuda a mantener el c�digo ordenado
+		También ayuda a mantener el código ordenado
-		forzando a dividir funciones en trozos m�s modulares y
+		forzando a dividir funciones en trozos más modulares y
-		bien definidos &mdash; si la indentaci�n va m�s all� del
+		bien definidos &mdash; si la indentación va más allá del
-		margen derecho, significa que la funci�n est� mal
+		margen derecho, significa que la función está mal
-		dise�ada y que debiera dividirse para hacerla m�s modular
+		diseñada y que debiera dividirse para hacerla más modular
 		o bien, repensarla.
 </para>
 <para>
-		Los tabuladores de 8 espacios para indentaci�n tambi�n
+		Los tabuladores de 8 espacios para indentación también
-		ayudan al dise�o de funciones que encajen bien en la pantalla,
+		ayudan al diseño de funciones que encajen bien en la pantalla,
-		lo cual significa que las personas puedan entender el c�digo
+		lo cual significa que las personas puedan entender el código
-		sin tener que desplazarse atr�s y adelante para entenderlo.
+		sin tener que desplazarse atrás y adelante para entenderlo.
 </para>
 <para>
 		Si usas &Emacs;, entonces puedes seleccionar el estilo de
-		indentaci�n del n�cleo de Linux incluyendo en el
+		indentación del núcleo de Linux incluyendo en el
 		archivo <filename>.emacs</filename> lo siguiente:
 	<programlisting>
 (add-hook 'c-mode-common-hook
 (lambda ()
 (c-set-style "k&amp;r")
 (setq c-basic-offset 8)))</programlisting>
 	En los nuevos Emacs o con el nuevo cc-mode, puedes ser capaz
-	de hacerlo m�s simple con:
+	de hacerlo más simple con:
 	<programlisting>
 (add-hook 'c-mode-common-hook
 (lambda ()
 (c-set-style "linux")))</programlisting>
 </para>
 <para>
-		El estilo de indentaci�n de GNU es el predeterminado para
+		El estilo de indentación de GNU es el predeterminado para
-		&Emacs;, as� que no es necesario agregar nada en el
+		&Emacs;, así que no es necesario agregar nada en el
 		archivo <filename>.emacs</filename> para habilitarlo.
-		Si deseas seleccionarlo expl�citamente, sustituye
+		Si deseas seleccionarlo explícitamente, sustituye
-		�gnu� por �linux� en el ejemplo anterior.
+		«gnu» por «linux» en el ejemplo anterior.
 </para>
 <para>
 		Si usas &Vim;, entonces puedes seleccionar el estilo
-		de indentaci�n del n�cleo de Linux incluyendo el
+		de indentación del núcleo de Linux incluyendo el
 		siguiente fragmento en el archivo
 		<filename>.vimrc</filename>:
 	<programlisting>
 set ts=8
 endif</programlisting>
 </para>
 <para>
 		Como alternativa puedes seleccionar el estilo de
-		indentaci�n de GNU en &Vim; usando lo siguiente en
+		indentación de GNU en &Vim; usando lo siguiente en
 		el archivo <filename>.vimrc</filename>:
 	<footnote>
 	  <para>
-	    Gracias a Tomas &Ouml;gren por proporcionar este c�digo.
+	    Gracias a Tomas &Ouml;gren por proporcionar este código.
 	  </para>
 	</footnote>:
 	<programlisting>
 augroup C
 augroup END</programlisting>
 </para>
 <note>
 	<para>
-	  Si sabe personalizar el estilo de indentaci�n en otros
+	  Si sabe personalizar el estilo de indentación en otros
-	  editores populares, por favor h�ganoslo saber y as� podemos
+	  editores populares, por favor háganoslo saber y así podemos
 	  expandir este documento.
 	</para>
 </note>
 </sect2>
 <sect2 id="naming">
 <title>Convenciones de nombres</title>
 <para>
-		Es importante seguir una buena convenci�n de nombres para
+		Es importante seguir una buena convención de nombres para
-		los s�mbolos de los programas.   Es espec�ficamente
+		los símbolos de los programas.   Es específicamente
-		importante para las bibliotecas, ya que no deber�a
+		importante para las bibliotecas, ya que no debería
 		ensuciarse el espacio de nombres global &mdash; es muy
-		molesto cuando una biblioteca tiene s�mbolos nombrados
+		molesto cuando una biblioteca tiene símbolos nombrados
 		desordenadamente que chocan con nombres que pueda
 		querer usar en sus programas.
 </para>
 <para>
-		Los nombres de las funciones deber�an ser de la forma
+		Los nombres de las funciones deberían ser de la forma
 		<function>modulo_submodulo_operacion</function>, por ejemplo,
 		<function>gnome_canvas_set_scroll_region</function> o
-		<function>gnome_mime_get_keys</function>.  Esta convenci�n
+		<function>gnome_mime_get_keys</function>.  Esta convención
-		elimina las colisiones de nombres de s�mbolos entre m�dulos.
+		elimina las colisiones de nombres de símbolos entre módulos.
 		Es muy importante para las bibliotecas.
 </para>
 <para>
-		Los s�mbolos deben tener nombres descriptivos.  Como Linus
+		Los símbolos deben tener nombres descriptivos.  Como Linus
 		dice, no use <function>cntusr()</function>, sino que use
 		<function>count_active_users()</function>.  Esto permite
-		que el c�digo sea m�s f�cil de leer y casi se auto
+		que el código sea más fácil de leer y casi se auto
 		documenta.
 </para>
 <para>
 		Intente usar las mismas convenciones de nombre que tienen
 		GTK+ y las bibliotecas de GNOME:
 	<itemizedlist>
 	  <listitem>
 	    <para>
-		  Los nombres de las funciones en min�sculas, con l�neas
+		  Los nombres de las funciones en minúsculas, con líneas
 		  de subrayado para separar palabras, tal como:
 	      <function>gnome_canvas_set_scroll_region()</function>,
 	      <function>gnome_mime_get_keys()</function>.
 	    </para>
 	  </listitem>
 	  <listitem>
 	    <para>
-		  Las macros y las enumeraciones en may�sculas, con l�neas
+		  Las macros y las enumeraciones en mayúsculas, con líneas
 		  de subrayado para separar palabras, tal como:
 	      <symbol>GNOMEUIINFO_SUBTREE()</symbol> para una macro y
 	      <symbol>GNOME_INTERACT_NONE</symbol> para un valor
 		  enumerado.
 	    </para>
 	  </listitem>
 	  <listitem>
 	    <para>
 		  Los nombres de tipos y estructuras usan una mezcla de
-		  may�sculas y min�sculas, tal como:
+		  mayúsculas y minúsculas, tal como:
 	      <symbol>GnomeCanvasItem</symbol>,
 		  <symbol>GnomeIconList</symbol>.
 	    </para>
 	  </listitem>
 	</itemizedlist>
-	Al utilizar l�neas de subrayado para separar palabras el
+	Al utilizar líneas de subrayado para separar palabras el
-	c�digo estar� menos apretado y facilita la edici�n, ya
+	código estará menos apretado y facilita la edición, ya
 	que puede usar las secuencias de teclas que permiten
-	navegar entre palabras m�s r�pidamente en cualquier editor.
+	navegar entre palabras más rápidamente en cualquier editor.
 </para>
 <para>
-		Si est�s escribiendo una biblioteca, entonces puedes necesitar
+		Si estás escribiendo una biblioteca, entonces puedes necesitar
-		exportar s�mbolos que ser�n usados s�lo dentro de la
+		exportar símbolos que serán usados sólo dentro de la
 		biblioteca.   Por ejemplo, dos de los archivos objeto que
 		componen la biblioteca <filename>libfoo.so</filename> pueden
-		requerir acceder a s�mbolos ubicados en el otro archivo,
+		requerir acceder a símbolos ubicados en el otro archivo,
-		pero se tiene la intenci�n que �stos s�mbolos no sean
+		pero se tiene la intención que éstos símbolos no sean
 		utilizados desde los programas de usuario.  En este caso,
-		coloca una l�nea de subrayado antes del nombre de la
+		coloca una línea de subrayado antes del nombre de la
-		funci�n y haz que la primera palabra siga la convenci�n
+		función y haz que la primera palabra siga la convención
-		est�ndar m�dulo/subm�dulo.  Por ejemplo, podr�as tener
+		estándar módulo/submódulo.  Por ejemplo, podrías tener
-		una funci�n llamada
+		una función llamada
 	<function>_foo_internal_frobnicate()</function>.
 </para>
 <!-- Consistency in Naming -->
 <sect3 id="consist">
 	<title>Consistencia entre nombres</title>
 	<para>
 	  Es importante que las variables se nombren de manera
-	  consistente.  Por ejemplo, un m�dulo que manipula una
+	  consistente.  Por ejemplo, un módulo que manipula una
 	  lista puedes elegir nombrar las variables que mantienen
-	  un puntero a la lista como �<symbol>l</symbol>�,
+	  un puntero a la lista como «<symbol>l</symbol>»,
 	  por elegancia y simplicidad.  Sin embargo, es importante que
-	  un m�dulo que manipula widgets y tama�os no use variables
+	  un módulo que manipula widgets y tamaños no use variables
-	  llamadas �<symbol>w</symbol>� tanto para
+	  llamadas «<symbol>w</symbol>» tanto para
-	  widgets y anchos (�width�) (como en valores de ancho/alto);
+	  widgets y anchos («width») (como en valores de ancho/alto);
-	  esto podr�a hacer que el c�digo sea inconsistente
+	  esto podría hacer que el código sea inconsistente
-	  y dif�cil de leer.
+	  y difícil de leer.
 	</para>
 	<para>
-	  Por supuesto, nombre muy cortos y elegantes solamente deber�an
+	  Por supuesto, nombre muy cortos y elegantes solamente deberían
 	  ser usados para variables locales de funciones.
-	  Nunca llame una variable global �<symbol>x</symbol>�; use
+	  Nunca llame una variable global «<symbol>x</symbol>»; use
-	  un nombre m�s largo que indique lo que significa.
+	  un nombre más largo que indique lo que significa.
 	</para>
 </sect3>
 </sect2>
 <!-- Cleanliness -->
 <sect2 id="clean">
 <title>Limpieza</title>
 <para>
-		El c�digo de GNOME debe ser tan limpio como sea posible.
+		El código de GNOME debe ser tan limpio como sea posible.
-		Esto implica usar un estilo de indentaci�n consistente
+		Esto implica usar un estilo de indentación consistente
-		y una buena convenci�n para nombrar s�mbolos, como se
+		y una buena convención para nombrar símbolos, como se
-		ha indicado anteriormente.  Esto tambi�n implica lo
+		ha indicado anteriormente.  Esto también implica lo
 		siguiente.
 </para>
 <para>
 		Aprender el uso correcto de la palabra reservada
 		<symbol>static</symbol>.
-		<emphasis>No</emphasis> declarar todos los s�mbolos como
+		<emphasis>No</emphasis> declarar todos los símbolos como
 		globales.  Esto tiene la ventaja de poder usar nombres
-		m�s cortos dentro de las funciones en un s�lo archivo
+		más cortos dentro de las funciones en un sólo archivo
 		fuente, ya que no son globalmente visibles y por
 		consiguiente no necesitas emplear el prefijo
-		m�dulo/subm�dulo.
+		módulo/submódulo.
 </para>
 <para>
 		Aprender el uso correcto de la palabra reservada
-		<symbol>const</symbol>.  �sala consistentemente,
+		<symbol>const</symbol>.  Úsala consistentemente,
-		as� permitir�s al compilador que atrape muchos
+		así permitirás al compilador que atrape muchos
-		errores est�pidos.
+		errores estúpidos.
 </para>
 <para>
-		Si tienes una funci�n que retorna un puntero a
+		Si tienes una función que retorna un puntero a
 		un dato interno que se supone que el usuario
-		no debe liberar, deber�as usar el modificador
+		no debe liberar, deberías usar el modificador
-		<symbol>const</symbol>.  Este avisar� al usuario si intenta
+		<symbol>const</symbol>.  Este avisará al usuario si intenta
-		hacer alguna operaci�n incorrecta, por ejemplo:
+		hacer alguna operación incorrecta, por ejemplo:
 	<programlisting>
 const char *gnome_mime_get_info (const char *info);</programlisting>
-		El compilador avisar� si el usuario intenta liberar
+		El compilador avisará si el usuario intenta liberar
 		la cadena retornada.  Esto puede atrapar muchos
 		errores.
 </para>
 <para>
-		Si tienes �valores m�gicos� en el programa o
+		Si tienes «valores mágicos» en el programa o
 		biblioteca, usa macros que los definan en vez de usarlos
-		directamente en el c�digo:
+		directamente en el código:
 	<programlisting>
 /* Amount of padding for GUI elements */
 #define GNOME_PAD          8
 #define GNOME_PAD_SMALL    4
 <para>
 		Si tienes una lista de valores posibles para una variable,
 		no uses macros para ellas, usa enum para darle
 		un nombre de tipo &mdash; esto permite disponer de nombres
-		simb�licos en un depurador.  Adem�s, no uses
+		simbólicos en un depurador.  Además, no uses
-		�int� para almacenar un valor enumerado; usa
+		«int» para almacenar un valor enumerado; usa
 		el tipo enum.  Esto le permite al compilador atrapar
-		los errores por t�, permiti�ndole al depurador mostrar los
+		los errores por tí, permitiéndole al depurador mostrar los
 		valores apropiados y hacer obvios los valores que una
-		variable puede tomar. A continuaci�n un ejemplo:
+		variable puede tomar. A continuación un ejemplo:
 	<programlisting>
 /* Shadow types */
 typedef enum {
 	GTK_SHADOW_NONE,
 	GNOME_CANVAS_UPDATE_CLIP       = 1 << 2,
 	GNOME_CANVAS_UPDATE_VISIBILITY = 1 << 3,
 	GNOME_CANVAS_UPDATE_IS_VISIBLE = 1 << 4
 };]]></programlisting>
-	Esto hace m�s f�cil modificar la lista de valores y menos
+	Esto hace más fácil modificar la lista de valores y menos
-	propenso a error que especificando los valores a mano.  Tambi�n
+	propenso a error que especificando los valores a mano.  También
-	permite usar estos valores como s�mbolos en un depurador.
+	permite usar estos valores como símbolos en un depurador.
 </para>
 <para>
-		No escribas c�digo ofuscado, intenta que sea espartano.
+		No escribas código ofuscado, intenta que sea espartano.
-		Para clarificar una expresi�n, no uses m�s par�ntesis que
+		Para clarificar una expresión, no uses más paréntesis que
-		los necesarios.  Usa espacios antes de los par�ntesis y
+		los necesarios.  Usa espacios antes de los paréntesis y
-		despu�s de las comas y tambi�n alrededor de los operadores
+		después de las comas y también alrededor de los operadores
 		binarios.
 </para>
 <para>
-		No escribas hacks en el c�digo.  En vez de escribir un
+		No escribas hacks en el código.  En vez de escribir un
-		hack feo, reescribe el c�digo para que quede limpio,
+		hack feo, reescribe el código para que quede limpio,
 		extensible y mantenible.
 </para>
 <para>
-		Aseg�rate de que el c�digo compila absolutamente sin ning�n
+		Asegúrate de que el código compila absolutamente sin ningún
-		aviso del compilador.  Esto te ayudar� a atrapar errores
+		aviso del compilador.  Esto te ayudará a atrapar errores
-		est�pidos.  Usa los prototipos de las funciones en los
+		estúpidos.  Usa los prototipos de las funciones en los
 		archivos de encabezados de forma consistente.
 </para>
 <para>
 		Dentro de GNOME puedes usar la macro de Autoconf
 <symbol>GNOME_COMPILE_WARNINGS</symbol> en el archivo
-<filename>configure.in</filename>.  Esto permitir� contar
+<filename>configure.in</filename>.  Esto permitirá contar
 		con un buen conjunto de avisos del compilador de una manera
 		portable.
 </para>
 <para>
-		Comenta el c�digo.  Coloca comentarios antes de
+		Comenta el código.  Coloca comentarios antes de
-		cada funci�n para decir que hace.  No digas c�mo lo hace
+		cada función para decir que hace.  No digas cómo lo hace
-		a menos que sea absolutamente necesario; deber�a ser
+		a menos que sea absolutamente necesario; debería ser
-		obvio al leer el c�digo.  Si no lo fuera, entonces
+		obvio al leer el código.  Si no lo fuera, entonces
-		puedes desear reescribirla hasta que sea f�cil de
+		puedes desear reescribirla hasta que sea fácil de
 		entender.
 </para>
 <para>
 		Cuando documentes las funciones de la API de una biblioteca,
 		sigue las directrices indicadas en el archivo
 <filename>gnome-libs/devel-docs/api-comment-style.txt</filename>.
-		Esto permite que el c�digo fuente pueda proporcionar documentaci�n
+		Esto permite que el código fuente pueda proporcionar documentación
-		en l�nea, que posteriormente se extrae mediante el sistema
+		en línea, que posteriormente se extrae mediante el sistema
 <application>gtk-doc</application> para crear un manual DocBook
-	  	de forma autom�tica.
+	  	de forma automática.
 </para>
 <!-- Portability considerations -->
 <sect3 id="portability">
 	<title>Consideraciones de portabilidad</title>
 	<para>
 	  Se construye GNOME en muchas plataformas diferentes.
-	  Se puede asumir que ser�n plataformas m�s o menos tipo Unix;
+	  Se puede asumir que serán plataformas más o menos tipo Unix;
 	  hasta el momento GNOME no ha sido portado a sistema no-Unix,
-	  as� que se puede asumir que los servicios est�ndares de
+	  así que se puede asumir que los servicios estándares de
-	  Unix estar�n disponibles.<footnote>
+	  Unix estarán disponibles.<footnote>
 	    <para>
-		  �Servicios est�ndar de Unix? Por supuesto que estamos
+		  ¿Servicios estándar de Unix? Por supuesto que estamos
 		  bromeando.
 	    </para>
 	  </footnote>
 	</para>
 	<para>
 	  Recuerda que el mundo no es tu propio equipo con GNU/Linux;
-	  las gente realmente usa otros tipos de m�quinas.
+	  las gente realmente usa otros tipos de máquinas.
 	</para>
 	<para>
-	  Intenta no usar extensiones espec�ficas de
+	  Intenta no usar extensiones específicas de
-	  <application>GCC</application> debido a que �stas no
+	  <application>GCC</application> debido a que éstas no
-	  funcionar�n con otros compiladores.  Si realmente debes
+	  funcionarán con otros compiladores.  Si realmente debes
 	  hacer uso de tal cosa, ve la forma en que se hace
 	  en <application>Glib</application> con el conjunto de
-	  macros G_GNUC; aseg�rate tambi�n de incluir c�digo
+	  macros G_GNUC; asegúrate también de incluir código
-	  que funcione con compiladores ISO C. Si s�lo tienes
+	  que funcione con compiladores ISO C. Si sólo tienes
 	  disponible <application>GCC</application>, aprende a usar
 	  las opciones <option>-ansi -pedantic</option> que
-	  permiten probar c�digo sospechoso.
+	  permiten probar código sospechoso.
 	</para>
 	<para>
 	  Recuerda que algunas plataformas no disponen de
 	  <application>GCC</application> o que
 	  <application>GDB</application> puede ser inusable en ellos,
-	  y se querr�n usar otros compiladores y depuradores.
+	  y se querrán usar otros compiladores y depuradores.
 	</para>
 </sect3>
 <!-- GTK+-related Issues -->
 <sect3 id="gtk">
-	<title>T�picos relacionados con GTK+</title>
+	<title>Tópicos relacionados con GTK+</title>
 	<para>
-	  GTK+ permite hacer mucha magia y ofuscaci�n con manejadores
+	  GTK+ permite hacer mucha magia y ofuscación con manejadores
-	  de se�al, pasar cerraduras y conjuntos de datos.  Si te
+	  de señal, pasar cerraduras y conjuntos de datos.  Si te
 	  encuentras utilizando muchos
 	  <function>gtk_object_set_data()</function> en un mismo lugar,
-	  o estas pasando estados de forma extra�a a trav�s de manejadores
+	  o estas pasando estados de forma extraña a través de manejadores
-	  de se�ales, reescribe el c�digo.  Si necesitas adjuntar muchos
+	  de señales, reescribe el código.  Si necesitas adjuntar muchos
 	  datos a un objeto en particular, entonces es un buen candidato
-	  para una nueva clase derivada, que no s�lo har� al c�digo
+	  para una nueva clase derivada, que no sólo hará al código
-	  m�s limpio, sino que tambi�n lo har� m�s extensible.
+	  más limpio, sino que también lo hará más extensible.
 	</para>
 	<para>
-Mucha de la heur�stica en manejadores de eventos complicadas
+Mucha de la heurística en manejadores de eventos complicadas
-	  a menudo se pueden reemplazar limpiando el c�digo a trav�s
+	  a menudo se pueden reemplazar limpiando el código a través
-	  de una m�quina de estados.  Esto es �til cuando se quieren
+	  de una máquina de estados.  Esto es útil cuando se quieren
-	  implementar cosas truculentas como selecci�n y comportamientos
+	  implementar cosas truculentas como selección y comportamientos
-	  de arrastrado, y har� al c�digo m�s f�cil de depurar y extender.
+	  de arrastrado, y hará al código más fácil de depurar y extender.
 	</para>
 </sect3>
 </sect2>
 </sect1>
 <!-- Correctness and Robustness -->
 <sect1 id="robust">
-<title>Correcci�n y robustez</title>
+<title>Corrección y robustez</title>
 <para>
-	  Es extremadamente importante que el c�digo de GNOME sea
+	  Es extremadamente importante que el código de GNOME sea
-	  correcto y robusto.  Esto significa que el c�digo deber�a hacer
+	  correcto y robusto.  Esto significa que el código debería hacer
-	  lo que se espera que haga y deber�a manejar bien las condiciones
+	  lo que se espera que haga y debería manejar bien las condiciones
-	  de excepci�n.  Aunque esto pueda parecer obvio, esta secci�n
+	  de excepción.  Aunque esto pueda parecer obvio, esta sección
-	  dar� algunas ideas para asegurar la correcci�n de tu c�digo
+	  dará algunas ideas para asegurar la corrección de tu código
 	  de GNOME.  Esto es muy importante, ya que los usuarios esperan
 	  y merecen un software confiable que se ejecute correctamente
 	  y que no se caiga.
 </para>
 <!-- Ensuring Consistency -->
 <sect2 id="ensure">
-<title>C�mo asegurar la consistencia</title>
+<title>Cómo asegurar la consistencia</title>
 <para>
 	  	<!-- FIXME: Buscar un mejor termino para "assertion" -->
-		Utiliza las macros de aserci�n de Glib para asegurarte
+		Utiliza las macros de aserción de Glib para asegurarte
 		que el estado de un programa es consistente.  Estas macros
-		ayudan a localizar errores muy r�pidamente y se gastar�
+		ayudan a localizar errores muy rápidamente y se gastará
 		mucho menos tiempo en el depurado si se emplean de forma
 		generosa y consistente.
 </para>
 <para>
-		Inserta verificaciones de sanidad en el c�digo en puntos
+		Inserta verificaciones de sanidad en el código en puntos
-		importantes como es el inicio de funciones p�blicas, al
+		importantes como es el inicio de funciones públicas, al
-		final de c�digo que realiza una b�squeda que siempre
+		final de código que realiza una búsqueda que siempre
 		debe ser exitosa y en cualquier lugar donde
 		el rango de valores calculados es importante.
 </para>
 </sect2>
 <para>
 		Las aserciones y precondiciones ayudan a asegurar que
 		el estado de un programa es consistente.  Glib proporciona
 		macros para colocar aserciones y precondiciones en el
-		c�digo.  Deber�as usarlas libremente; a cambio podr�s
+		código.  Deberías usarlas libremente; a cambio podrás
-		localizar errores muy r�pidamente y ocupar�s menos tiempo
+		localizar errores muy rápidamente y ocuparás menos tiempo
 		rastreando errores con el depurador.
 </para>
 <para>
 		Existen macros de Glib para precondiciones, las cuales
-		emiten un mensaje cuando una condici�n falla y retornan
+		emiten un mensaje cuando una condición falla y retornan
-		de la funci�n desde donde fueron llamadas.  Debieran ser
+		de la función desde donde fueron llamadas.  Debieran ser
 		usadas en el inicio de las funciones.
 	<variablelist>
 	  <varlistentry>
 	    <term><function>g_return_if_fail
-		(condici�n)</function></term>
+		(condición)</function></term>
 	    <listitem>
 	      <para>
-			Retorna desde la l�nea actual de la funci�n si la
+			Retorna desde la línea actual de la función si la
-		<symbol>condici�n</symbol> es falsa.
+		<symbol>condición</symbol> es falsa.
 	      </para>
 	    </listitem>
 	  </varlistentry>
 	  <varlistentry>
-	    <term><function>g_return_val_if_fail (condici�n,
+	    <term><function>g_return_val_if_fail (condición,
 		valor)</function></term>
 	    <listitem>
 	      <para>
 			Retorna el <symbol>valor</symbol> indicado desde
-			la funci�n actual si la <symbol>condici�n</symbol>
+			la función actual si la <symbol>condición</symbol>
 			es falsa.
 	      </para>
 	    </listitem>
 	  </varlistentry>
 	</variablelist>
 </para>
 <para>
-		Tambi�n existen macros para aserciones.  Estas emitir�n
+		También existen macros para aserciones.  Estas emitirán
-		un mensaje cuando una condici�n falle y llamar� a la
+		un mensaje cuando una condición falle y llamará a la
-		funci�n <function>abort(3)</function> para terminar el
+		función <function>abort(3)</function> para terminar el
 		programa.  Debieran ser usadas para asegurarse la
-		consistencia para c�digos internos.
+		consistencia para códigos internos.
 	<variablelist>
 	  <varlistentry>
-	    <term><function>g_assert (condici�n)</function></term>
+	    <term><function>g_assert (condición)</function></term>
 	    <listitem>
 	      <para>
-			Aborta el programa si la <symbol>condici�n</symbol>
+			Aborta el programa si la <symbol>condición</symbol>
 			es falsa.
 	      </para>
 	    </listitem>
 	  </varlistentry>
 	</variablelist>
 </para>
 <para>
 		Estas funciones debieran emplearse para imponer
-		precondiciones en el c�digo y verificar su correcci�n
+		precondiciones en el código y verificar su corrección
 		&mdash; piensa en ellas como verificaciones de sanidad
 		en los programas.  Debieras usarlas libremente como
-		asistencia para atrapar los errores r�pidamente; una
+		asistencia para atrapar los errores rápidamente; una
 		vez que el programa se encuentre completamente depurado,
-		puedes compilarlo con estas macros deshabilitadas y as�
+		puedes compilarlo con estas macros deshabilitadas y así
-		evitar a�adirle sobrecarga al momento de ejecutarlos.
+		evitar añadirle sobrecarga al momento de ejecutarlos.
 </para>
 <para>
 		Las macros <function>g_return_*()</function> debieran
-		emplearse al inicio de las funciones p�blicas de las
+		emplearse al inicio de las funciones públicas de las
 		bibliotecas, para asegurarse de que los argumentos que se pasan
-		a ellas sean correctos y tengan un rango v�lido.  Si
+		a ellas sean correctos y tengan un rango válido.  Si
-		una funci�n no retorna valor (por ejemplo, retorna
+		una función no retorna valor (por ejemplo, retorna
 		<symbol>void</symbol>), debieras usar
 		<function>g_return_if_fail()</function>.  En caso contrario,
 		debiera usar <function>g_return_val_if_fail()</function>
 		para retornar un valor &lsquo;seguro&rsquo;.  Cuando
-		se invoca una funci�n de biblioteca que usa estas macros
+		se invoca una función de biblioteca que usa estas macros
-		con un argumento incorrecto , se producir� un
+		con un argumento incorrecto , se producirá un
-		mensaje de error y continuar� la ejecuci�n.  El
+		mensaje de error y continuará la ejecución.  El
-		programa cliente podr� tener alg�n sobresalto, hacer
+		programa cliente podrá tener algún sobresalto, hacer
-		nada o caerse, pero al menos sabr�
+		nada o caerse, pero al menos sabrá
-		<emphasis>d�nde</emphasis> se le ha pasado un valor
+		<emphasis>dónde</emphasis> se le ha pasado un valor
-		incorrecto a la funci�n.
+		incorrecto a la función.
 </para>
 <para>
 	  	La macro <function>g_assert()</function> debiera usarse para
 		asegurar la consistencia interna de una biblioteca o
-		programa.  En vez de retornar de la funci�n y continuar
+		programa.  En vez de retornar de la función y continuar
-		la ejecuci�n si la condici�n falla,
+		la ejecución si la condición falla,
-		<function>g_assert()</function> producir� en mensaje de error
+		<function>g_assert()</function> producirá en mensaje de error
-		e inmediatamente abortar� el programa.  Esto es para
+		e inmediatamente abortará el programa.  Esto es para
-		evitar que el programa contin�e ejecut�ndose en un
+		evitar que el programa continúe ejecutándose en un
 		estado inconsistente.  Debieras usar esta macro para
-		asegurarte de que el programa o biblioteca est� usando
+		asegurarte de que el programa o biblioteca está usando
 		valores internos sanos.
 </para>
 <para>
 		La macro <function>g_assert_not_reached()</function> se
-		usa para marcar el lugar en el c�digo que nunca
+		usa para marcar el lugar en el código que nunca
 		debiera producirse.  Por ejemplo, si tienes una
-		cl�usula <symbol>switch</symbol> y piensas que manejas
+		cláusula <symbol>switch</symbol> y piensas que manejas
 		todos los valores posibles en las etiquetas
 		<symbol>case</symbol>, entonces debieras colocar
 		<function>g_assert_not_reached()</function> en la
 		etiqueta <symbol>default</symbol> para asegurarte de que
-		el c�digo nunca llegue all� (podr�a significar que
+		el código nunca llegue allá (podría significar que
-		ha perdido alg�n valor o que el programa se encuentra
+		ha perdido algún valor o que el programa se encuentra
 		incorrecto).
 </para>
 <para>
-		Estas macros ayudan a encontrar errores m�s r�pido
+		Estas macros ayudan a encontrar errores más rápido
-		a trav�s de avisos que se producen tan pronto como
+		a través de avisos que se producen tan pronto como
-		el programa alcanza un estado incosistente.  �salos
+		el programa alcanza un estado incosistente.  Úsalos
-		frecuentemente y encontrar�s muchos errores m�s
+		frecuentemente y encontrarás muchos errores más
-		f�cilmente.
+		fácilmente.
 </para>
 </sect2>
 <!-- GTK+-related Issues -->
 <sect2 id="assert-gtk">
-<title>T�picos relacionados con GTK+</title>
+<title>Tópicos relacionados con GTK+</title>
 <para>
 		Debe ser cuidadoso cuando escribas manejadores de eventos
 		&mdash; asegurate de que los eventos son manipulados en
 		las situaciones apropiadas.  Es necesario asegurarse de
-		que los manejadores de se�ales tengan los prototipos
+		que los manejadores de señales tengan los prototipos
 		correctos.  Esto es muy importante.  Recuerda que no
-		todos los prototipos de manejadores de se�al se parecen
+		todos los prototipos de manejadores de señal se parecen
 		a lo siguiente:
 	<programlisting>
 static void my_handler (GtkWidget *widget, gpointer data);</programlisting>
-	Por ejemplo, los manejadores de eventos tienen un par�metro
+	Por ejemplo, los manejadores de eventos tienen un parámetro
 	extra de evento y retornan <symbol>gint</symbol>.  Revisa los
 	archivos de encabezado de GTK+ cuando necesites verificarlo.
 </para>
 <para>
-		Aseg�rate que el programa trata de una forma apropiada
+		Asegúrate que el programa trata de una forma apropiada
 		todas las acciones generadas por el usuario.  Recuerda
 		que el usuario puede cerrar una ventana en cualquier
-		momento a trav�s del administrador de ventanas; tenlo
+		momento a través del administrador de ventanas; tenlo
-		presente y escribe el c�digo necesario para manejar esta
+		presente y escribe el código necesario para manejar esta
-		situaci�n.
+		situación.
 </para>
 <para>
-		Si verificas los modificadores de teclas con una m�scara
+		Si verificas los modificadores de teclas con una máscara
 		de estado de eventos, por ejemplo,
 		<keycombo><keycap>Control</keycap><keycap>F10</keycap></keycombo>
 		escribe lo siguiente:
 	<programlisting>
 	Esto es necesario; si en vez de lo anterior escribes:
 	<programlisting>
 if (event-&gt;keysym == GDK_F10 &amp;&amp; event-&gt;state == GDK_CONTROL_MASK)</programlisting>
-		entonces el programa no funcionar� correctamente si el
+		entonces el programa no funcionará correctamente si el
 		usuario tiene, por ejemplo, activada la tecla
 		<keycap>NumLock</keycap> &mdash; <keycap>NumLock</keycap>
-		tambi�n es un modificador, y si est� activado, entonces
+		también es un modificador, y si está activado, entonces
-		la m�scara de estado del evento no ser� como se espera
+		la máscara de estado del evento no será como se espera
 		en el segundo ejemplo.
 </para>
 <!-- Visuals and Colormaps -->
 <sect3 id="visuals">
 	<title>Vistas y mapas de color</title>
 	<para>
-	  <!-- FIXME: Buscar un t�rmino adecuado para "Visual" en
+	  <!-- FIXME: Buscar un término adecuado para "Visual" en
 	       vez de "vista" -->
-	  Algunos usuarios utilizan tarjetas de v�deo avanzadas
+	  Algunos usuarios utilizan tarjetas de vídeo avanzadas
-	  (por ejemplo, SGIs y Suns) que soportan m�ltiples vistas
+	  (por ejemplo, SGIs y Suns) que soportan múltiples vistas
-	  sim�ltaneamente.  Una vista define la representaci�n en memoria
+	  simúltaneamente.  Una vista define la representación en memoria
 	  que usa un dispositivo de hardware para almacenar los
-	  contenidos de una imagen.  Muchas tarjetas de v�deo de
+	  contenidos de una imagen.  Muchas tarjetas de vídeo de
-	  PC soportan s�lo una vista a la vez, pero el hardware
+	  PC soportan sólo una vista a la vez, pero el hardware
 	  avanzado puede tener diferentes ventanas y pixmaps en
-	  diferentes vistas simult�neamente.
+	  diferentes vistas simultáneamente.
 	</para>
 	<para>
 	  Es importante entender las vistas y mapas de colores si
-	  vas a escribir c�digo que crea ventanas y pixmaps por tus
+	  vas a escribir código que crea ventanas y pixmaps por tus
 	  propios medios, en vez de utilizar las funciones de alto
-	  nivel como GnomeCanvas y GnomePixmap.  Para mayor informaci�n,
+	  nivel como GnomeCanvas y GnomePixmap.  Para mayor información,
-	  lea el manual de programaci�n de Xlib.
+	  lea el manual de programación de Xlib.
 	</para>
 	<para>
-	  En general, s�lo necesitas recordar que la vista y el mapa
+	  En general, sólo necesitas recordar que la vista y el mapa
-	  de colores de un �rea de dibujo debe coincidir con los de
+	  de colores de un área de dibujo debe coincidir con los de
-	  otra �rea de dibujo si deseas copiar un trozo desde la
+	  otra área de dibujo si deseas copiar un trozo desde la
-	  primera �rea de dibujo a la segunda.  Si no son las mismas,
+	  primera área de dibujo a la segunda.  Si no son las mismas,
-	  podr�as obtener el mensaje �BadMatch error� del servidor X y
+	  podrías obtener el mensaje «BadMatch error» del servidor X y
-	  tu aplicaci�n muy probablemente abortar� su ejecuci�n.
+	  tu aplicación muy probablemente abortará su ejecución.
 	</para>
 	<para>
-	  Si creas un contexto gr�fico (GC) y lo compartes para pintar
+	  Si creas un contexto gráfico (GC) y lo compartes para pintar
-	  en varias �reas de dibujo, aseg�rate que todas ellas tengan
+	  en varias áreas de dibujo, asegúrate que todas ellas tengan
 	  la misma vista y mapa de colores que fue definido para el
-	  GC.  Lo mismo se aplica si quieres copiar un �rea desde un
+	  GC.  Lo mismo se aplica si quieres copiar un área desde un
 	  pixmap a una ventana; ambos deben tener la misma vista y mapa
 	  de colores.
 	</para>
 	<para>
-	  Si no est�s seguro de que tu c�digo lo hace correctamente,
+	  Si no estás seguro de que tu código lo hace correctamente,
 	  pregunta educadamente, en una de las listas de correo de
 	  desarrollo de GNOME, si alguien puede realizar una prueba con
-	  una tarjeta de video que soporta esta caracter�stica.  Dicha
+	  una tarjeta de video que soporta esta característica.  Dicha
-	  persona sabr� como arreglar el problema y te dir� al respecto.
+	  persona sabrá como arreglar el problema y te dirá al respecto.
 	</para>
 </sect3>
 </sect2>
 <!-- Unix-related Issues -->
 <para>
 		Verifica los valores de retorno de <emphasis>todas</emphasis>
 		las llamadas al sistema que el programa realice.  Recuerda
 		que muchas de las llamadas al sistema pueden ser
 		interrumpidas (por ejemplo, la llamada retorna
-	    <symbol>-1</symbol> y <symbol>errno</symbol> ser� definido a
+	    <symbol>-1</symbol> y <symbol>errno</symbol> será definido a
 	    <symbol>EINTR</symbol>) y deben reiniciarse.
 </para>
 <para>
-		No asumas, por ejemplo, que la funci�n
+		No asumas, por ejemplo, que la función
-		<function>write(2)</function> escribir� el buffer completo
+		<function>write(2)</function> escribirá el buffer completo
 		de una vez; tienes que verificar el valor de retorno, el cual
-		indica el n�mero de bytes escritos e intenta nuevamente
+		indica el número de bytes escritos e intenta nuevamente
 		hasta que sea cero.  Si el valor de retorno es
 	    <symbol>-1</symbol>, recuerda
 		verificar el valor de errno y manejar el error
 		apropiadamente.
 </para>
 <para>
-		Si la aplicaci�n llama a la funci�n <function>fork(2)</function>
+		Si la aplicación llama a la función <function>fork(2)</function>
 		sin llamar a <function>execve(2)</function>, recuerda que
 		el proceso hijo no puede hacer llamadas X.  Normalmente se
-		puede diagnosticar este problema a trav�s de un oscuro
+		puede diagnosticar este problema a través de un oscuro
 		mensaje de error de Xlib.
 </para>
 <para>
-		Lee el libro �Advanced programming in the Unix
+		Lee el libro «Advanced programming in the Unix
-		environment�, de Richard Stevens, para aprender acerca de
+		environment», de Richard Stevens, para aprender acerca de
-		todos estos teassertmas y aseg�rate que tus programas usan
+		todos estos teassertmas y asegúrate que tus programas usan
 		la API de Unix de forma correcta.  Si no deseas asegurarte
 		del uso correcto de las llamadas Unix, pregunta en las
 		listas de correo.
 </para>
 </sect2>
 <sect1 id="security">
 <title>Consideraciones de seguridad</title>
 <para>
-	  La seguridad es un tema complejo y en esta secci�n no se
+	  La seguridad es un tema complejo y en esta sección no se
 	  puede explicar ni de lejos todo lo relacionado.
-	  Intentaremos indicar las situaciones m�s comunes donde tus
+	  Intentaremos indicar las situaciones más comunes donde tus
 	  programas deben interesarse por la seguridad.
 </para>
 <para>
-	  Es muy f�cil crear hoyos de seguridad a trav�s de la creaci�n
+	  Es muy fácil crear hoyos de seguridad a través de la creación
 	  incorrecta de archivos temporales en <filename>/tmp</filename>.
-	  Debes garantizar que los archivos que usar�s no existen al
+	  Debes garantizar que los archivos que usarás no existen al
-	  momento de su creaci�n.  Usar un nombre de archivo ��nico�
+	  momento de su creación.  Usar un nombre de archivo «único»
-	  e �impredecible� no es suficiente; debes garantizar que el archivo
+	  e «impredecible» no es suficiente; debes garantizar que el archivo
-	  con ese nombre no ser� creado por alguien m�s entre el tiempo
+	  con ese nombre no será creado por alguien más entre el tiempo
 	  en que se determina el nombre y el tiempo en que es efectivamente
-	  creado (b�sicamente los ataques involucran que un tercero
+	  creado (básicamente los ataques involucran que un tercero
-	  cree un enlace simb�lico al archivo que ellos quieren
+	  cree un enlace simbólico al archivo que ellos quieren
 	  sobreescribir).
 </para>
 <para>
-	  Afortunadamente, esto es f�cil de hacer.  Usa el siguiente trozo
+	  Afortunadamente, esto es fácil de hacer.  Usa el siguiente trozo
-	  de c�digo:
+	  de código:
 <programlisting>
 	char *filename;
 	int fd;
 		fd = open (filename, O_CREAT | O_EXCL | O_TRUNC | O_RDWR, 0600);
 		free (filename);
 	} while (fd == -1);</programlisting>
-Recuerde liberar <symbol>filename</symbol> usando la funci�n
+Recuerde liberar <symbol>filename</symbol> usando la función
 	  <function>free()</function> y llamar a las funciones
 	  <function>close()</function> y <function>unlink()</function>
-	  con el archivo respectivo cuando haya terminado; aqu�
+	  con el archivo respectivo cuando haya terminado; aquí
 	  liberamos <symbol>filename</symbol> con <function>free()</function>
-	  inmediatamente y as� no causar� una p�rdida de memoria.
+	  inmediatamente y así no causará una pérdida de memoria.
 </para>
 <para>
-	  Si deseas usar la biblioteca est�ndar de E/S, puede usar la
+	  Si deseas usar la biblioteca estándar de E/S, puede usar la
-	  funci�n <function>fdopen()</function> para transformar el
+	  función <function>fdopen()</function> para transformar el
 	  descriptor de archivo en <symbol>FILE *</symbol>, o puedes
-	  usar la funci�n <function>tmpfile()</function> para hacerlo
+	  usar la función <function>tmpfile()</function> para hacerlo
 	  en un solo paso.
 </para>
 <para>
-	  Intenta no usar buffers de tama�o fijo.  Los buffers de tama�o
+	  Intenta no usar buffers de tamaño fijo.  Los buffers de tamaño
-	  fijo para cadenas constituyen los t�picas fuentes de hoyos
+	  fijo para cadenas constituyen los típicas fuentes de hoyos
 	  explotables que pueden llegar a oscuros errores.  Si definitivamente
-	  debes usar buffers de tama�o fijo para cadenas, usa la funci�n
+	  debes usar buffers de tamaño fijo para cadenas, usa la función
-<function>g_snprintf()</function> para especificar el tama�o
+<function>g_snprintf()</function> para especificar el tamaño
-	  m�ximo del buffer.
+	  máximo del buffer.
 </para>
 <para>
-	  Glib proporciona la, muy conveniente, funci�n
+	  Glib proporciona la, muy conveniente, función
 <function>g_strdup_printf()</function>, la cual funciona como
-<function>sprintf()</function> pero autom�ticamente
+<function>sprintf()</function> pero automáticamente
-	  localizar� un buffer con el tama�o correcto.  El valor de retorno
+	  localizará un buffer con el tamaño correcto.  El valor de retorno
-	  de esta funci�n debiera ser liberada usando
+	  de esta función debiera ser liberada usando
-	  <function>g_free()</function>.  A menudo es m�s conveniente de
+	  <function>g_free()</function>.  A menudo es más conveniente de
 	  usar que <function>g_snprintf()</function>, ya que esta no
-	  limita el tama�o de las cadenas que un programa puede manipular.
+	  limita el tamaño de las cadenas que un programa puede manipular.
 </para>
 <para>
-	  Si deseas concatenar un grupo de cadenas, puedes usar la funci�n
+	  Si deseas concatenar un grupo de cadenas, puedes usar la función
 <function>g_strconcat()</function>, la cual recibe una lista
 	  variable de cadenas y un puntero a <symbol>NULL</symbol>
-	  como �ltimo argumento.
+	  como último argumento.
 </para>
 <para>
 <emphasis>Bajo ninguna circunstancia</emphasis> crees un
 	  programa GTK+ con setuid root.  Las bibliotecas de GTK+ y
-	  GNOME son grandes y complejas y no han tenido auditor�as
+	  GNOME son grandes y complejas y no han tenido auditorías
 	  de seguridad.  En cualquier caso, no debieras querer que
-	  una pieza tan grande c�digo sea setuid root.  Si definitivamente
+	  una pieza tan grande código sea setuid root.  Si definitivamente
 	  requieres usar privilegios de root para algo, escribe un
 	  programa que sea la interfaz de usuario como un proceso
 	  normal, sin privilegios y crea un programa nexo que
 	  tenga setuid y se encargue de realizar la operaciones
-	  �peligrosas�.  Adem�s, notifica a las listas
+	  «peligrosas».  Además, notifica a las listas
 	  de correo de desarrollo de GNOME indicando que requieres
-	  que alguien realice una auditor�a de seguridad a tu
+	  que alguien realice una auditoría de seguridad a tu
 	  programa nexo.
 </para>
 <para>
-	  En general, si no est�s seguro si puedes crear un riesgo de
+	  En general, si no estás seguro si puedes crear un riesgo de
 	  seguridad, pregunte en las listas de correo de desarrollo
 	  de GNOME.
 </para>
 <para>
-	  Puedes leer m�s sobre temas de seguridad que debieras encontrar
+	  Puedes leer más sobre temas de seguridad que debieras encontrar
-	  cuando programes una aplicaci�n Unix en el documento
+	  cuando programes una aplicación Unix en el documento
-<ulink URL="http://www.fish.com/security/murphy.html">�Murphy's
+<ulink URL="http://www.fish.com/security/murphy.html">«Murphy's
-Law and Computer Security�</ulink>, de Wietse Wenema.
+Law and Computer Security»</ulink>, de Wietse Wenema.
 	  Hay otros documentos de seguridad en <ulink
 URL="http://www.fish.com/security">el sitio fish.com</ulink>
-	  que podr�as encontrar interesante.
+	  que podrías encontrar interesante.
 </para>
 <para>
-	  Puedes encontrar muchas otras gu�as �tiles para escribir programas
+	  Puedes encontrar muchas otras guías útiles para escribir programas
 	  seguros en <ulink
-url="http://www.dwheeler.com/secure-programs">�Secure
+url="http://www.dwheeler.com/secure-programs">«Secure
-Programming for Linux and Unix HOWTO�</ulink>.
+Programming for Linux and Unix HOWTO»</ulink>.
 </para>
 </sect1>
 <!-- Performace -->
 <sect1 id="performance">
 <title>Rendimiento</title>
 <para>
-	  No leas esta secci�n hasta que est�s seguro que tu programa est�
+	  No leas esta sección hasta que estés seguro que tu programa está
-	  correcto, por ejemplo, cuando est�s seguro que funciona
+	  correcto, por ejemplo, cuando estés seguro que funciona
-	  correctamente y no tiene errores.  Es m�s importante que
+	  correctamente y no tiene errores.  Es más importante que
-	  el c�digo sea correcto a que sea r�pido.  Un programa lento
+	  el código sea correcto a que sea rápido.  Un programa lento
-	  pero correcto es mucho mejor a uno r�pido pero con errores.
+	  pero correcto es mucho mejor a uno rápido pero con errores.
 </para>
 <para>
 	  Si quieres optimizar tu programa, el primer paso es determinar
-	  un perfil al programa ejecut�ndolo con datos de la vida real
+	  un perfil al programa ejecutándolo con datos de la vida real
-	  y recopilar puntos calientes que requieran optimizaci�n.
+	  y recopilar puntos calientes que requieran optimización.
-	  Esto ayudar� a determinar los lugares que necesitan optimizarse.
+	  Esto ayudará a determinar los lugares que necesitan optimizarse.
-	  Es importante que nunca adelantes la optimizaci�n si no tienes
+	  Es importante que nunca adelantes la optimización si no tienes
-	  una idea clara sobre donde est� el problema.  Podr�as terminar
+	  una idea clara sobre donde está el problema.  Podrías terminar
 	  perdiendo el tiempo en agilizar una rutina que no es la causa
-	  del cuello de boteLla y como resultado podr�as terminar ofuscando
+	  del cuello de boteLla y como resultado podrías terminar ofuscando
-	  dicha rutina.  Esto podr�a reducir la legibilidad y mantenibilidad
+	  dicha rutina.  Esto podría reducir la legibilidad y mantenibilidad
-	  del c�digo sin ganancia visible en velocidad.
+	  del código sin ganancia visible en velocidad.
 </para>
 <para>
-	  Un c�digo sencillo es bueno porque es f�cil de entender y
+	  Un código sencillo es bueno porque es fácil de entender y
-	  mantener.  Si puedes escribir c�digo simple que adem�s sea
+	  mantener.  Si puedes escribir código simple que además sea
-	  potente y r�pido, tanto mejor.  Si tienes un trozo de c�digo
+	  potente y rápido, tanto mejor.  Si tienes un trozo de código
-	  inteligente pero que no es f�cil de seguir, entonces docum�ntalo
+	  inteligente pero que no es fácil de seguir, entonces documéntalo
 	  para que las personas no lo estropeen accidentalmente.
 </para>
 <para>
-	  No escribas c�digo que sea dif�cil de leer y mantener por el
+	  No escribas código que sea difícil de leer y mantener por el
-	  s�lo hecho de hacerlo m�s r�pido.  En cambio, prefiere un algoritmo
+	  sólo hecho de hacerlo más rápido.  En cambio, prefiere un algoritmo
-	  agradable y claro e implem�ntalo claramente.
+	  agradable y claro e impleméntalo claramente.
 </para>
 <para>
 	  Hacer un buen trabajo en el caso general es a menudo mejor que
-	  tener muchos casos especiales.  S�lo provee casos especiales
+	  tener muchos casos especiales.  Sólo provee casos especiales
-	  cuando se han identificado puntos d�biles en el programa.
+	  cuando se han identificado puntos débiles en el programa.
 </para>
 <!-- List Management in Glib -->
 <sect2 id="list">
-<title>Administraci�n de listas en Glib</title>
+<title>Administración de listas en Glib</title>
 	<para>
 		  Evita emplear construcciones que terminen ralentizando
 		  los algoritmos.  Si usas
 		  <function>g_list_insert_sorted()</function> o
-	  <function>g_list_append()</function> sin ning�n cuidado,
+	  <function>g_list_append()</function> sin ningún cuidado,
-		  f�cilmente puedes tener un algoritmo que se ejecuta en
+		  fácilmente puedes tener un algoritmo que se ejecuta en
 		  tiempo proporcional a O(n<superscript>2</superscript>).
-		  Normalmente puedes crear listas hacia atr�s, usando
+		  Normalmente puedes crear listas hacia atrás, usando
-	  <function>g_list_prepend()</function>, e invirti�ndola
+	  <function>g_list_prepend()</function>, e invirtiéndola
 		  cuando hayas terminado usando
 		  <function>g_list_reverse()</function>.  Esta es una
-		  operaci�n O(n).  Y si necesitas una lista ordenada, puedes
+		  operación O(n).  Y si necesitas una lista ordenada, puedes
-		  crearla de la misma forma (hacia atr�s) y una vez terminado,
+		  crearla de la misma forma (hacia atrás) y una vez terminado,
 		  usar <function>g_list_sort()</function>.
 	</para>
 	<para>
 		  Si necesitas una lista ordenada en todo momento, puede ser
-		  mejor emplear un estructura de �rbol o un h�brido
+		  mejor emplear un estructura de árbol o un híbrido
-		  lista/�rbol.  Si necesitas construir una lista a�adiendo
+		  lista/árbol.  Si necesitas construir una lista añadiendo
-		  nodos a ella, mant�n un puntero al final de la lista
+		  nodos a ella, mantén un puntero al final de la lista
-		  y ve cambi�ndola seg�n sea apropiado; esto te permitir�
+		  y ve cambiándola según sea apropiado; esto te permitirá
 		  insertar un nodo al inicio o al final en un tiempo constante.
 	</para>
 </sect2>
 </sect1>
 <!-- Localization -->
 <sect1 id="l10n">
-<title>Localizaci�n</title>
+<title>Localización</title>
 <para>
 	  Se pretende que GNOME pueda ejecutarse en distintas localidades
 	  y lenguajes, y los programas debieran tener esto en cuenta.  No
-	  tienes que localizar los programas, s�lo debes permitir que �stos
+	  tienes que localizar los programas, sólo debes permitir que éstos
 	  sean traducibles y localizables.
 </para>
 <para>
 	  Debes recordar que los diferentes idiomas humanos tienen diferentes
-	  gram�ticas, as� que no debieras suponer la forma de estructurar
+	  gramáticas, así que no debieras suponer la forma de estructurar
 	  cada frase.  Esto es importante, por ejemplo, cuando se
 	  construyen cadenas a partir de trozos separados.
 </para>
 <para>
-	  La concatenaci�n normalmente no es la forma correcta de construir
+	  La concatenación normalmente no es la forma correcta de construir
 	  una cadena para que sea presentada al usuario.  Normalmente terminan
 	  en mensajes que no pueden ser traducidos correctamente en todos
 	  los idiomas.  En vez de concatenar, intenta usar
 	  <function>g_strdup_printf()</function>, por ejemplo:
 	/* Una mejor forma */
 	char *message = g_strdup_printf (_("Hello, %s, would you like fries with that?"),
 					 name);</programlisting>
-	  Esto permitir� al traductor mover %s donde corresponda seg�n
+	  Esto permitirá al traductor mover %s donde corresponda según
-	  lo requiera la gram�tica del idioma en el cual trabaja.
+	  lo requiera la gramática del idioma en el cual trabaja.
 </para>
 <para>
-	  Recuerda que no todos los idiomas forman los plurales a�adiendo
+	  Recuerda que no todos los idiomas forman los plurales añadiendo
-	  una �s� a las palabras.  Adem�s, las estructuras de
+	  una «s» a las palabras.  Además, las estructuras de
 	  frases pueden cambiar con los plurales.  Por ejemplo,
 <programlisting>
 	/* Una forma no muy buena */
 	printf (_("%d happy monkey%s bouncing on the bed."),
 	  distintas maneras en distintos idiomas, y la estructura
 	  completa de la frase puede cambiar.
 </para>
 <para>
-	  Si el programa muestra fechas u horas, usa la funci�n
+	  Si el programa muestra fechas u horas, usa la función
 <function>strftime()</function> para darles formato como
-	  cadenas.  Esto se encargar� de usar la representaci�n
+	  cadenas.  Esto se encargará de usar la representación
-	  adecuada de fecha y hora de acuerdo a la definici�n local
+	  adecuada de fecha y hora de acuerdo a la definición local
-	  del usuario.  Adem�s, si el programa debe generar una
+	  del usuario.  Además, si el programa debe generar una
-	  representaci�n visual de un calendario, recuerda que en
+	  representación visual de un calendario, recuerda que en
-	  algunos pa�ses se considera como primer d�a de la semana
+	  algunos países se considera como primer día de la semana
 	  el domingo y no el lunes.  El programa debiera permitir
 	  ambas formas de calendarios.
 </para>
 <para>
-	  Si el programa usa medidas, aseg�rate de permitir tanto
+	  Si el programa usa medidas, asegúrate de permitir tanto
-	  el sistema m�trico decimal como el sistema imperial (o anglosaj�n).
+	  el sistema métrico decimal como el sistema imperial (o anglosajón).
 </para>
 </sect1>
 <!-- Binary Compatibility -->
 <title>Compatibilidad binaria en las bibliotecas</title>
 <para>
 	  Para bibliotecas estables y ya liberadas, es muy importante
 	  intentar preservar la compatibilidad binaria en las revisiones
-	  mayores del c�digo.  Los desarrolladores de bibliotecas deben
+	  mayores del código.  Los desarrolladores de bibliotecas deben
 	  intentar no alienar a los usuarios realizando de forma frecuente
 	  cambios que sean binariamente incompatibles en bibliotecas que
-	  son de producci�n.  Por supuesto, en aquellas bibliotecas que se
+	  son de producción.  Por supuesto, en aquellas bibliotecas que se
-	  encuentran en desarrollo o est�n etiquetadas como no finalizadas
+	  encuentran en desarrollo o están etiquetadas como no finalizadas
 	  puedes realizar tantos cambios como se necesiten.
 </para>
 <para>
-	  Una biblioteca t�picamente exporta un n�mero de interfaces.  Estas
+	  Una biblioteca típicamente exporta un número de interfaces.  Estas
 	  incluyen nombres de rutinas, las firmas o prototipos de estas
 	  rutinas, variables globales, estructuras, campos de estructura
 	  (tanto los tipos como su significado), el significado de los
-	  valores enumerados y la sem�ntica de los archivos que la
+	  valores enumerados y la semántica de los archivos que la
 	  biblioteca crea.  Mantener compatibilidad binaria significa que
-	  estas interfaces no cambiar�n.  Puedes a�adir nuevas interfaces
+	  estas interfaces no cambiarán.  Puedes añadir nuevas interfaces
 	  sin romper la compatibilidad binaria, pero no puedes cambiar
-	  las ya existentes, ya que los programas antiguos no se ejecutar�n
+	  las ya existentes, ya que los programas antiguos no se ejecutarán
 	  correctamente.
 </para>
 <para>
-	  Esta secci�n incluye un n�mero de ideas acerca de como lograr
+	  Esta sección incluye un número de ideas acerca de como lograr
-	  que el c�digo de una biblioteca sea compatible con sus
+	  que el código de una biblioteca sea compatible con sus
 	  versiones anteriores.
 </para>
 <para>
 	  Mantener la compatibilidad binaria significa que los programas
-	  y archivos objetos que fueron compilados con una versi�n
+	  y archivos objetos que fueron compilados con una versión
-	  previa del c�digo continuar�n funcionando sin recompilar a�n
+	  previa del código continuarán funcionando sin recompilar aún
 	  cuando la biblioteca sea reemplazada. Es posible encontrar
-	  una descripci�n detallada en el nodo info
+	  una descripción detallada en el nodo info
-<filename>(libtool)Interfaces</filename> de la documentaci�n
+<filename>(libtool)Interfaces</filename> de la documentación
 	  de GNU libtool.
 </para>
 <!-- Private Information in Structures -->
 <sect2 id="private">
-<title>Informaci�n privada en las estructuras</title>
+<title>Información privada en las estructuras</title>
 <para>
-		En el sistema GNOME es una tarea muy com�n crear un
+		En el sistema GNOME es una tarea muy común crear un
 		nuevo <structname>GtkObject</structname> para crear
 		una estructura cuyo primer miembro corresponde a la
 		clase de la cual hereda este objeto y posteriormente
-		un n�mero de variables de instancia que se a�aden
+		un número de variables de instancia que se añaden
-		despu�s del primer miembro.
+		después del primer miembro.
 </para>
 <para>
-		Este esquema de dise�o normalmente lleva a que el c�digo
+		Este esquema de diseño normalmente lleva a que el código
-		sea dif�cil de actualizar y cambiar: si se quiere
+		sea difícil de actualizar y cambiar: si se quiere
 		extender un objeto donde se necesita mantener su estado
 		interno, los programadores necesitan recurrir a varios
-		hacks para mantener el mismo tama�o de las estructuras.
+		hacks para mantener el mismo tamaño de las estructuras.
-		Esto hace dif�cil agregar nuevos campos a las estructuras
+		Esto hace difícil agregar nuevos campos a las estructuras
-		p�blicas sin romper la compatibilidad binaria, ya que
+		públicas sin romper la compatibilidad binaria, ya que
-		los campos de la estructura pueden cambiar y el tama�o
+		los campos de la estructura pueden cambiar y el tamaño
 		de las estructuras pueden variar.
 </para>
 <para>
 		Por consiguiente, se sugiere una estrategia que puedan
 		adoptar los desarrolladores en el momento de crear nuevos
-		objetos.  Esta estrategia asegurar� la compatibilidad
+		objetos.  Esta estrategia asegurará la compatibilidad
-		binaria y al mismo tiempo mejorar� la legibilidad y
+		binaria y al mismo tiempo mejorará la legibilidad y
-		mantenibilidad del c�digo.
+		mantenibilidad del código.
 </para>
 <para>
 		La idea es que, para un objeto dado, el programador
 		debiera crear tres archivos: el primero que contiene
 		el contrato entre la biblioteca y el usuario (esto
 		es el archivo de encabezado que se instala en el
-		sistema); el segundo contiene la implementaci�n del
+		sistema); el segundo contiene la implementación del
-		objeto; y el tercer archivo contiene la definici�n
+		objeto; y el tercer archivo contiene la definición
 		de la estructura para los campos privados o internos
-		que no necesitan estar en la estructura p�blica.
+		que no necesitan estar en la estructura pública.
 </para>
 <para>
-		La API p�blica de la estructura podr�a incluir un
+		La API pública de la estructura podría incluir un
-		puntero a un elemento privado, el cual podr�a
+		puntero a un elemento privado, el cual podría
 		apuntar a los datos privado de la instancia. Las
-		rutinas de implementaci�n podr�a dereferenciar
+		rutinas de implementación podría dereferenciar
 		este punto para acceder a los datos privados; por
 		supuesto, el puntero apunta a la estructura que se
 		localiza privadamente.
 </para>
 <para>
 		Por ejemplo, imagina que se crea el objeto GnomeFrob.
-		La implementaci�n del widget ser� dividido en tres
+		La implementación del widget será dividido en tres
 		archivos:
 	<table>
 	  <title>Archivos que muestran el widget de ejemplo
 	  GnomeFrob</title>
 	      </row>
 	    </thead>
 	    <tbody>
 	      <row>
 		<entry><filename>gnome-frob.h</filename></entry>
-		<entry>API p�blica de GnomeFrob</entry>
+		<entry>API pública de GnomeFrob</entry>
 	      </row>
 	      <row>
 		<entry><filename>gnome-frob.c</filename></entry>
-		<entry>Implementaci�n del objeto Gnomefrob</entry>
+		<entry>Implementación del objeto Gnomefrob</entry>
 	      </row>
 	      <row>
 		<entry><filename>gnome-frob-private.h</filename></entry>
-		<entry>Datos privados de la implementaci�n de GnomeFrob.
+		<entry>Datos privados de la implementación de GnomeFrob.
 			Debieras querer usar esto si planea compartir los
-			datos privados a trav�s de varios archivos C. Si
+			datos privados a través de varios archivos C. Si
-			limitas el uso de la informaci�n privada a s�lo un
+			limitas el uso de la información privada a sólo un
 			archivo, no necesita esto, ya que al definir la
-			estructura en el archivo de implementaci�n se lograr�
+			estructura en el archivo de implementación se logrará
 			el mismo efecto.</entry>
 	      </row>
 	    </tbody>
 	  </tgroup>
 	</table>
 </para>
 <para>
 	<example>
-	  <title>Ejemplo de la API p�blica de <filename>gnome-frob.h</filename>
+	  <title>Ejemplo de la API pública de <filename>gnome-frob.h</filename>
 	  </title>
 	  <programlisting>
 typedef struct _GnomeFrob GnomeFrob;
 typedef struct _GnomeFrobPrivate GnomeFrobPrivate;
 gboolean frobbed;
 } GnomeFrobPrivate;</programlisting>
 	</example>
 	<example>
-	  <title>Ejemplo de la implementaci�n de
+	  <title>Ejemplo de la implementación de
 	  <filename>gnome-frob.c</filename>.</title>
 	  <programlisting>
 void gnome_frob_frobate (GnomeFrob *frob)
 {
 g_return_if_fail (frob != NULL);
 	frob->priv->frobbed = TRUE;
 }</programlisting>
 	</example>
-		F�jese en el uso de prototipos de estructura: esto permite que
+		Fíjese en el uso de prototipos de estructura: esto permite que
-		el compilador realice m�s verificaciones en tiempo de
+		el compilador realice más verificaciones en tiempo de
-		compilaci�n respecto a los tipos que estan siendo empleados.
+		compilación respecto a los tipos que estan siendo empleados.
 </para>
 <para>
-		Este esquema es �til en algunas situaciones, particularmente
+		Este esquema es útil en algunas situaciones, particularmente
 		en el caso en el cual vale la pena almacenar un puntero
 		extra para una instancia del objeto.  Si esto no fuera
-		posible, el programador necesitar�a recurrir a otros
+		posible, el programador necesitaría recurrir a otros
 		artilugios para evitar este problema.
 </para>
 <para>
-		El prop�sito de tener un archivo de encabezado privado
+		El propósito de tener un archivo de encabezado privado
 		extra para las estructuras privadas es permitir que las
-		clases derivadas usen esta informaci�n.  Por supuesto,
+		clases derivadas usen esta información.  Por supuesto,
-		una buena pr�ctica de programaci�n indicar�a que debiera
+		una buena práctica de programación indicaría que debiera
-		proveerse de interfaces o m�todos de acceso precisamente
+		proveerse de interfaces o métodos de acceso precisamente
 		para que el programador no tenga que lidiar con
 		estructuras privadas.  Se debiera intentar alcanzar un
-		balance entre buena pr�ctica y pragmatismo cuando se
+		balance entre buena práctica y pragmatismo cuando se
-		crean estructuras privadas y m�todos de acceso p�blicos.
+		crean estructuras privadas y métodos de acceso públicos.
 </para>
 <para>
-		Podr�an aparecer algunos problemas, por ejemplo, cuando
+		Podrían aparecer algunos problemas, por ejemplo, cuando
-		se ha enviado un versi�n del c�digo y que est� siendo
+		se ha enviado un versión del código y que está siendo
 		ampliamente usado y se desea extenderlo.  Hay dos
 		soluciones para esto.
 </para>
 <para>
-		La primera opci�n es encontrar un campo puntero en la
+		La primera opción es encontrar un campo puntero en la
-		estructura p�blica que pueda hacerse privada y
+		estructura pública que pueda hacerse privada y
 		reemplazar el puntero a la parte privada de la
-		estructura.  Esto preserva el tama�o de la estructura
+		estructura.  Esto preserva el tamaño de la estructura
-		ya que, para los prop�sitos de GNOME, se puede
+		ya que, para los propósitos de GNOME, se puede
-		asumir que los punteros son todos del mismo tama�o.
+		asumir que los punteros son todos del mismo tamaño.
 		Se puede hacer que este campo apunte a la parte privada
-		de la estructura que ser� ubicada por la funci�n que
+		de la estructura que será ubicada por la función que
-		originalmente creaba la estructura p�blica.  Es
+		originalmente creaba la estructura pública.  Es
 		importante que este campo no sea llamado
 		<structfield>private</structfield>, se trata de
-		una palabra reservada de C++ y crear� problemas cuando
+		una palabra reservada de C++ y creará problemas cuando
 		el archivo de encabezado sea usado desde programas
-		fuentes C++ &mdash; mejor ll�malo
+		fuentes C++ &mdash; mejor llámalo
 		<structfield>priv</structfield>.  Por supuesto, este
-		tipo de cambios s�lo funcionar� si el antiguo campo
+		tipo de cambios sólo funcionará si el antiguo campo
-		puntero solamente era usado para prop�sitos internos;
+		puntero solamente era usado para propósitos internos;
-		si los usuarios de la biblioteca hab�an tenido acceso
+		si los usuarios de la biblioteca habían tenido acceso
-		a dicho campo para cualquier prop�sito, ser� necesario
+		a dicho campo para cualquier propósito, será necesario
-		buscar otro campo o buscar una soluci�n diferente.
+		buscar otro campo o buscar una solución diferente.
 </para>
 <para>
 		Si la estructura original fue derivada de
 	<structname>GtkObject</structname> y no hay campos punteros
 	que puedan ser reemplazados, puedes usar la facilidad
 	de datos de objetos de GTK+.  Esto permite asociar punteros
-	a datos arbitrarios a objetos.  Usa la funci�n
+	a datos arbitrarios a objetos.  Usa la función
 	<function>gtk_object_set_data()</function> para adjuntar
 	valores o estructuras a un objeto y cuando requieras usarlos
-	la funci�n <function>gtk_object_get_data()</function>
+	la función <function>gtk_object_get_data()</function>
-	permitir� recuperar dichos valores.  Esto puede ser empleado
+	permitirá recuperar dichos valores.  Esto puede ser empleado
 	para adjuntar una estructura privada a un objeto GTK+.
-	Esto no es tan eficiente como el enfoque anterior, pero podr�a
+	Esto no es tan eficiente como el enfoque anterior, pero podría
-	no importar para el dominio particular de la aplicaci�n.  Si
+	no importar para el dominio particular de la aplicación.  Si
-	los datos ser�n accedidos frecuentemente, se pueden usar
+	los datos serán accedidos frecuentemente, se pueden usar
-	quarks en vez de cadenas para agregar y obtenerlos a trav�s
+	quarks en vez de cadenas para agregar y obtenerlos a través
 	de las funciones
 	<function>gtk_object_set_data_by_id()</function> y
 	<function>gtk_object_get_data_by_id()</function>,
 	respectivamente.
 </para>
 </sect1>
 <!-- Modifying Other People's Code -->
 <sect1 id="modify">
-<title>C�mo modificar el c�digo de otros</title>
+<title>Cómo modificar el código de otros</title>
 <para>
-	  GNOME es un proyecto de equipo, as� las contribuciones de
+	  GNOME es un proyecto de equipo, así las contribuciones de
-	  c�digo a programas de otras personas siempre son apreciadas.
+	  código a programas de otras personas siempre son apreciadas.
-	  Sigue los siguientes lineamientos cuando modifiques el c�digo
+	  Sigue los siguientes lineamientos cuando modifiques el código
 	  de otra persona.
 </para>
 <!-- General Etiquette -->
 <sect2 id="etiquette">
 <title>Etiqueta general</title>
 <para>
-		Siga el mismo estilo de indentaci�n usado en el c�digo
+		Siga el mismo estilo de indentación usado en el código
-		original.  El c�digo original perdurar� durante m�s tiempo
+		original.  El código original perdurará durante más tiempo
 		que el que le pueda dedicar, mantener las
-		contribuciones consistentes respecto a la indentaci�n
+		contribuciones consistentes respecto a la indentación
-		es m�s importante que forzar su estilo de indentaci�n
+		es más importante que forzar su estilo de indentación
-		en el c�digo.
+		en el código.
 </para>
 <para>
 		Aunque sus parches pueden implementar una
 		funcionalidad muy llamativa, es muy molesto para el
-		autor tener que reindentar el c�digo antes de aplicar
+		autor tener que reindentar el código antes de aplicar
-		un parche al c�digo principal.  As�, si el c�digo
+		un parche al código principal.  Así, si el código
 		original luce como:
 <programlisting>
 int
 sum_plus_square_of_indices (int *values, int nvalues)
 		total += values[i] + i * i;
 	return total;
 }</programlisting>
-	entonces no agregues una funci�n que luce como:
+	entonces no agregues una función que luce como:
 	<programlisting>
 int sum_plus_cube_of_indices(int *values, int nvalues) {
 int i,total;
 total+=values[i]+i*i*i;
 return total;
 }</programlisting>
-	En el segundo ejemplo, la indentanci�n y ubicaci�n de las
+	En el segundo ejemplo, la indentanción y ubicación de las
-	llaves no coincide con el c�digo original, no hay espacios
+	llaves no coincide con el código original, no hay espacios
-	alrededor de los operadores y el c�digo no se parecer�
+	alrededor de los operadores y el código no se parecerá
-	al original.  Sigue el estilo de programaci�n del autor
+	al original.  Sigue el estilo de programación del autor
-	original del programa y los parches que env�as tendr�n una mejor
+	original del programa y los parches que envías tendrán una mejor
 	oportunidad de ser aceptados.
 </para>
 <para>
-		No repares errores con artilugios o hacks r�pidos; rep�ralo
+		No repares errores con artilugios o hacks rápidos; repáralo
-		correctamente.  Tampoco a�adas caracter�sticas como hacks o
+		correctamente.  Tampoco añadas características como hacks o
-		con c�digo que no sea extensible; es mejor rehacer el
+		con código que no sea extensible; es mejor rehacer el
-		c�digo original para que sea extensible y luego agrega
+		código original para que sea extensible y luego agrega
-		la nueva caracter�stica, utilizando el c�digo como
+		la nueva característica, utilizando el código como
 		estructura.
 </para>
 <para>
-		La limpieza de c�digo siempre es bienvenida; si encuentras
+		La limpieza de código siempre es bienvenida; si encuentras
-		trozos de c�digo feos y sucios en GNOME, ser� muy
+		trozos de código feos y sucios en GNOME, será muy
-		apreciado si env�as parches que hagan el c�digo m�s
+		apreciado si envías parches que hagan el código más
-		agradable y f�cil de mantener.
+		agradable y fácil de mantener.
 </para>
 <para>
-		Como siempre, aseg�rate de que el c�digo que contribuye compila
+		Como siempre, asegúrate de que el código que contribuye compila
-		sin ning�n tipo de aviso, que tenga los prototipos correctos
+		sin ningún tipo de aviso, que tenga los prototipos correctos
 		y que sigan las directrices de este documento.
 </para>
 </sect2>
 <!-- Documenting Your Changes -->
 <sect2 id="document">
-<title>C�mo documentar los cambios</title>
+<title>Cómo documentar los cambios</title>
 <para>
-		GNOME utiliza los archivos &ChangeLog; est�ndar de GNU para
+		GNOME utiliza los archivos &ChangeLog; estándar de GNU para
-		documentar los cambios al c�digo.  Cada cambio que
+		documentar los cambios al código.  Cada cambio que
-		efect�es a un programa <emphasis>debe</emphasis> ser
+		efectúes a un programa <emphasis>debe</emphasis> ser
-		acompa�ado por una registro en el &ChangeLog;.  Esto
+		acompañado por una registro en el &ChangeLog;.  Esto
 		permite a las personas leer la historia de cambios
 		del programa de una manera sencilla.
 </para>
 <para>
-		Si usas &Emacs;, puede agregar las l�neas al
+		Si usas &Emacs;, puede agregar las líneas al
-		&ChangeLog; presionando �C-x 4 a�.
+		&ChangeLog; presionando «C-x 4 a».
 </para>
 <note>
 	<para>
 		Si conoces la forma de realizarlos para otros editores
 	* baz.c (ugly_function): Beautified by using a helper function.</programlisting>
 </para>
 <para>
-		Si agregas una nueva funci�n a una biblioteca, escribe
+		Si agregas una nueva función a una biblioteca, escribe
-		la referencia necesaria y la documentaci�n de programaci�n.
+		la referencia necesaria y la documentación de programación.
 		Puedes escribir una referencia a la documentacion
-		en l�nea usando el formato de comentarios descrito en
+		en línea usando el formato de comentarios descrito en
 		<filename>gnome-libs/devel-docs/api-comment-style.txt</filename>.
 		Si usas &Emacs;,
 		<filename>gnome-libs/tools/gnome-doc/gnome-doc.el</filename>
-		provee un acelerador que puede ser empleado para a�adir
+		provee un acelerador que puede ser empleado para añadir
-		una plantilla de documentaci�n al programa.
+		una plantilla de documentación al programa.
 </para>
 </sect2>
 <!-- Changing Code on CVS -->
 <sect2 id="change-cvs">
-<title>C�mo actualizar en CVS</title>
+<title>Cómo actualizar en CVS</title>
 <para>
 		Si tienes acceso de escritura en el repositorio CVS de GNOME,
-		debes seguir algunas pol�ticas adicionales.  Ya que est�s
+		debes seguir algunas políticas adicionales.  Ya que estás
 		trabajando en la copia maestra de los fuentes, debes tener
 		especial cuidado.
 </para>
 <para>
-		Si est�s reparando algo en un programa que est� en el CVS
+		Si estás reparando algo en un programa que está en el CVS
-		o si est�s a�adiendo una funcionalidad all�, y si no has
+		o si estás añadiendo una funcionalidad allí, y si no has
-		estado trabajando en dicho programa por un per�odo largo
+		estado trabajando en dicho programa por un período largo
 		de tiempo, pregunta al autor original antes de aplicar
-		sus parches.  Generalmente est� bien formular estas
+		sus parches.  Generalmente está bien formular estas
 		preguntas en la lista de correo
 		<filename>gnome-devel-list</filename>.
 </para>
 <para>
 		Una vez que el autor del programa te indique como un
 		&lsquo;contribuyente frecuente&rsquo;, puedes comenzar
 		aplicar los parches sin previo consentimiento. Si
-		quieres aplicar una reorganizaci�n mayor del c�digo,
+		quieres aplicar una reorganización mayor del código,
 		debieras preguntar primero.
 </para>
 <para>
-		Algunos m�dulos en el CVS tienen rama estable y de
+		Algunos módulos en el CVS tienen rama estable y de
 		desarrollo.  Normalmente el desarrollo debiera ir
 		en la rama HEAD en el CVS, y la rama estable debiera
-		mantenerse separadamente.  Generalmente no se a�aden
+		mantenerse separadamente.  Generalmente no se añaden
-		nuevas caracter�sticas a las rama estable; s�lo
+		nuevas características a las rama estable; sólo
 		se reparan errores.  Repara el error a la rama estable
-		y pregunta al autor principal sobre la pol�tica para
+		y pregunta al autor principal sobre la política para
 		mezclar parches en la rama de desarrollo; algunos
 		autores prefieren hacerlo por lotes, mientras hay otros
 		que prefieren mezclarlos inmediatamente.
 </para>
 <para>
-		Si trabajas en una caracter�stica experimental que
+		Si trabajas en una característica experimental que
-		podr�a estropear mucho c�digo, crea una rama en el CVS
+		podría estropear mucho código, crea una rama en el CVS
-		y realiza los cambios all�.  No los mezcles en la rama
+		y realiza los cambios allí.  No los mezcles en la rama
 		principal de desarrollo hasta que te encuentres
-		razonablemente seguro que funcionar� correctamente y que
+		razonablemente seguro que funcionará correctamente y que
-		se integrar� bien dentro del resto del c�digo.  El uso de
+		se integrará bien dentro del resto del código.  El uso de
-		una rama para trabajo en caracter�sticas experimentales
+		una rama para trabajo en características experimentales
-		te permitir� evitar interrumpir el trabajo de otros
+		te permitirá evitar interrumpir el trabajo de otros
 		desarrolladores.  Pregunte al autor principal antes de
 		mezclar tu rama y traer sus cambios a la parte principal
-		del �rbol.
+		del árbol.
 </para>
 <para>
 		Como siempre, agrega un registro en el &ChangeLog;
 		cuando realices un cambio.  Algunos autores tienen la
-		pol�tica de rechazar, correctamente, los cambios que
+		política de rechazar, correctamente, los cambios que
 		no tienen tal registro.
 </para>
 <para>
-		Algunas veces existen diferentes pol�ticas para los m�dulos,
+		Algunas veces existen diferentes políticas para los módulos,
-		verifica si el m�dulo contiene un archivo
+		verifica si el módulo contiene un archivo
-<filename>README.CVS</filename>.  Si es as�, lee ese archivo
+<filename>README.CVS</filename>.  Si es así, lee ese archivo
 		antes de realizar cambios.
 </para>
 <!-- Branches and Tags -->
 <sect3 id="branches">
 	<title>Ramas y marcas</title>
 	<para>
-	  Tenemos una convenci�n para nombrar las ramas y marcas o
+	  Tenemos una convención para nombrar las ramas y marcas o
 	  puntos de una rama en el repositorio de CVS de GNOME.
-	  Las marcas deben ser definidas despu�s que se libera cada
+	  Las marcas deben ser definidas después que se libera cada
 	  nueva version y deben ser de la forma
-	  �MODULE_MAJOR_MINOR_MICRO�, por ejemplo,
+	  «MODULE_MAJOR_MINOR_MICRO», por ejemplo,
-	  �GNOME_LIBS_1_0_53�.  Los puntos de una rama
+	  «GNOME_LIBS_1_0_53».  Los puntos de una rama
-	  deben ser de la forma �MODULE_BRANCH_ANCHOR�,
+	  deben ser de la forma «MODULE_BRANCH_ANCHOR»,
-	  como en �GNOME_LIBS_1_0_ANCHOR�.  Finalmente,
+	  como en «GNOME_LIBS_1_0_ANCHOR».  Finalmente,
-	  una rama ra�z en este punto debiera ser de la forma
+	  una rama raíz en este punto debiera ser de la forma
-	  �module-branch�, por ejemplo,
+	  «module-branch», por ejemplo,
-	  �gnome-libs-1-0�.  Usa esta convenci�n cuando
+	  «gnome-libs-1-0».  Usa esta convención cuando
 	  crees marcas, puntos de una rama y ramas.
 	</para>
 </sect3>
 <!-- Additional CVS Policies -->
 <sect3 id="cvs-policies">
-	<title>Pol�ticas adicionales del CVS</title>
+	<title>Políticas adicionales del CVS</title>
 	<para>
 	  CVS no proporciona un manera preconstruida para renombrar archivos
 	  o moverlos a otros directorios.  Debiera planificar
-	  cuidadosamente el �rbol del repositorio de tal forma que evite
+	  cuidadosamente el árbol del repositorio de tal forma que evite
 	  mover o renombrar archivos.
 	</para>
 	<para>
 	  En el caso que debas mover o renombrar un archivo en el CVS,
-	  <emphasis>NO EJECUTES</emphasis> �cvs remove�
+	  <emphasis>NO EJECUTES</emphasis> «cvs remove»
-	  y luego �cvs add�.  Si lo haces, los archivos
+	  y luego «cvs add».  Si lo haces, los archivos
-	  �nuevos� perder�n la capacidad de seguir su
+	  «nuevos» perderán la capacidad de seguir su
 	  historial de cambios, ya que desde el punto de vista de CVS
-	  ser�n archivos completamente nuevos en su revisi�n
+	  serán archivos completamente nuevos en su revisión
 	  inicial.  Un objetivo del repositorio CVS de GNOME es
 	  poder seguir la historia de los fuentes de manera
 	  precisa desde el inicio.
 	</para>
 	<para>
 	  <emphasis>Por favor</emphasis>, pregunte al mantenedor
 	  del CVS, esto es, una persona conocida con acceso shell
-	  a la m�quina con CVS, para realizar la cirug�a necesaria
+	  a la máquina con CVS, para realizar la cirugía necesaria
 	  para mover los archivos por ti.  Esto requiere
 	  conocimiento de la forma en que funciona CVS y debe ser
-	  hecho muy cuidadosamente.  La recuperaci�n de un error de
+	  hecho muy cuidadosamente.  La recuperación de un error de
-	   �cvs add/remove� es una tarea muy desagradable;
+	   «cvs add/remove» es una tarea muy desagradable;
 	  Si mueves archivo en esta forma equivocada, un mantenedor
-	  del CVS, quien tendr� que ir a reparar y realizar el trabajo
+	  del CVS, quien tendrá que ir a reparar y realizar el trabajo
-	  sucio, reclamar� las penas del infierno.  As� es que mejor
+	  sucio, reclamará las penas del infierno.  Así es que mejor
 	  pregunta por una persona que pueda mover los archivos por
 	  ti.
 	</para>
 </sect3>
 </sect2>
 </sect1>
 <!-- Maintaining a Package -->
 <sect1 id="maintain">
-<title>C�mo mantener un paquete</title>
+<title>Cómo mantener un paquete</title>
 <para>
 	  Un mantenedor de paquete es una persona que se preocupa de
 	  liberar versiones, integrar cambios de otras personas y,
 	  en general, ser responsable de un paquete.  Durante el
-	  per�odo de vida de un paquete, �ste puede cambiar de
+	  período de vida de un paquete, éste puede cambiar de
-	  mantenedores, por ejemplo, una persona que pierde inter�s
+	  mantenedores, por ejemplo, una persona que pierde interés
 	  o que ya no puede dedicarle tiempo suficiente como mantenedor.
 </para>
 <para>
-	  En conformidad con los Est�ndares de programaci�n de GNU, GNOME
+	  En conformidad con los Estándares de programación de GNU, GNOME
 	  usa GNU Autoconf para manejar la portabilidad  y GNU Automake
-	  para crear makefiles.  Automake hace especialmente f�cil
+	  para crear makefiles.  Automake hace especialmente fácil
-	  construir paquetes correctos, as� que si eres un mantenedor
+	  construir paquetes correctos, así que si eres un mantenedor
 	  de paquetes, debieras aprender como usarlo.  Autoconf y
-	  Automake tienen muchas �reas truculentas, as� que si�ntete
+	  Automake tienen muchas áreas truculentas, así que siéntete
 	  libre de pedir ayuda en las listas de desarrollo de GNOME
 	  si tienes preguntas sobre la forma correcta de construir
 	  makefiles para tu paquete.
 </para>
 <para>
-	  Un n�mero de personas regularmente contribuye con traducciones
+	  Un número de personas regularmente contribuye con traducciones
-	  localizadas de los cat�logos de mensajes en los paquetes de
+	  localizadas de los catálogos de mensajes en los paquetes de
 	  GNOME.  Para mantener las traducciones actualizadas tanto como
 	  sea posible, los mantenedores deben coordinarse con los
-	  traductores para que estos �ltimos puedan actualizar las
+	  traductores para que estos últimos puedan actualizar las
 	  traducciones a tiempo cuando se va a liberar una nueva
-	  versi�n del paquete.  Una buena forma de notificar a los
+	  versión del paquete.  Una buena forma de notificar a los
 	  traductores consiste en enviar un mensaje a
 <email>gnome-i18n@gnome.org</email> con suficientes
-	  d�as de anticipaci�n.  Esto les permitir� actualizar sus
+	  días de anticipación.  Esto les permitirá actualizar sus
 	  respectivas traducciones a tiempo para puedan ser incluidas
-	  en la siguiente versi�n liberada.
+	  en la siguiente versión liberada.
 </para>
 </sect1>
 <!-- Memory Leaks Agenda -->
 <sect1 id="memory-leak">
-<title>�Por qu� preocuparse por la p�rdida de memoria?</title>
+<title>¿Por qué preocuparse por la pérdida de memoria?</title>
 <para>
-	  �chale un vistazo a la lista de errores de Mozilla y una cosa es
+	  Échale un vistazo a la lista de errores de Mozilla y una cosa es
-	  clara: el nuevo c�digo que entra a Mozilla no es (o no ha sido)
+	  clara: el nuevo código que entra a Mozilla no es (o no ha sido)
-	  verificado suficientemente por p�rdida de memoria y problemas
+	  verificado suficientemente por pérdida de memoria y problemas
 	  de acceso.
 </para>
 <para>
-	  Las p�rdidas de memoria son malas por varias razones:
+	  Las pérdidas de memoria son malas por varias razones:
 <itemizedlist>
 	<listitem>
 	  <para>
-		Se comer� el �rea de intercambio lentamente. A la larga tu
+		Se comerá el área de intercambio lentamente. A la larga tu
-		programa, o hasta tu m�quina sucumbir�n.
+		programa, o hasta tu máquina sucumbirán.
 </para>
 <para>
 		Nadie quiere que su programa o biblioteca adquiera la
-		reputaci�n de ser una porquer�a s�lo porque uno ha sido un
+		reputación de ser una porquería sólo porque uno ha sido un
-		vago.  D�jaselo a las personas en Redmond.
+		vago.  Déjaselo a las personas en Redmond.
 		</para>
 	</listitem>
 	<listitem>
 	  <para>
 		Ocultan el mal uso de la memoria.  Si olvidas liberar la
 		memoria, no hay forma de atrapar las lecturas y
 		escrituras a esos trozos de memoria.  Si, posteriormente,
-		reparas la p�rdida, una parte completamente distinta
+		reparas la pérdida, una parte completamente distinta
-		del programa podr�a fallar.
+		del programa podría fallar.
 </para>
 	</listitem>
 	<listitem>
 <para>
-		Cuando se usan verificadores autom�ticos de memoria,
+		Cuando se usan verificadores automáticos de memoria,
 		nadie quiere ver 600 problemas, de los cuales 500
 		se encuentran en las bibliotecas de soporte. Lo que
 		deseas saber es que estaba todo limpio antes que comenzara
 	    el caos, y por lo tanto, esos problemas te corresponde a ti
 		arreglarlos.
 	  </para>
 	  <para>
 		Este es uno de los problemas de Mozilla actualmente:
-		pierde memoria sin parar as� que �c�mo vas a saber si has
+		pierde memoria sin parar así que ¿cómo vas a saber si has
 	    contribuido al problema?
 </para>
 	</listitem>
 </itemizedlist>
 </para>
 <sect2 id="memory-advice">
-<title>Algunos consejos contra la p�rdida de memoria.</title>
+<title>Algunos consejos contra la pérdida de memoria.</title>
 <para>
 <itemizedlist>
 <listitem>
 	    <para>
-	      Usa �<symbol>const</symbol>� donde sea posible (para
+	      Usa «<symbol>const</symbol>» donde sea posible (para
 		  punteros obviamente).
 </para>
 	    <para>
-	      Si un argumento es �<symbol>const</symbol>�, entonces
+	      Si un argumento es «<symbol>const</symbol>», entonces
-		  indudablemente la funci�n llamada no liberar� la memoria por
+		  indudablemente la función llamada no liberará la memoria por
 		  ti.
 </para>
 	    <para>
-		  Si el tipo de resultado de una funci�n es
+		  Si el tipo de resultado de una función es
-		  �<symbol>const</symbol>�, entonces
+		  «<symbol>const</symbol>», entonces
 		  claramente no eres responsable por liberarlo.
-		  <emphasis>Probablemente</emphasis> lo ser� para un resultado
+		  <emphasis>Probablemente</emphasis> lo será para un resultado
-		  distinto de �<symbol>const</symbol>� (que no sea un entero
+		  distinto de «<symbol>const</symbol>» (que no sea un entero
 		  o algo similar).
 </para>
 	    <para>
-		  F�jate en que, desafortunadamente, esto no funciona muy bien
+		  Fíjate en que, desafortunadamente, esto no funciona muy bien
 		  con los objetos que cuentan referencias.  Funciona bien
 		  con cadenas.
 </para>
 	    <para>
 		  Dado que C usa llamadas por valor, no tiene sentido
-		  aplicar �<symbol>const</symbol>� a tipos
+		  aplicar «<symbol>const</symbol>» a tipos
 		  <symbol>int</symbol>, <symbol>double</symbol> y similares.
 </para>
 	  </listitem>
 	  <listitem>
 </para>
 	    <itemizedlist>
 	      <listitem>
 		<para>
-			 Si una funci�n toma la propiedad de un objeto/referencia,
+			 Si una función toma la propiedad de un objeto/referencia,
-			 s� expl�cito acerca de ello.
+			 sé explícito acerca de ello.
 </para>
 	      </listitem>
 	      <listitem>
 		<para>
-			 Indica siempre si el que llama a la funci�n debiera
+			 Indica siempre si el que llama a la función debiera
 			 liberar/desreferenciar los resultados.
 </para>
 	      </listitem>
 	      <listitem>
 		<para>
-		  Documenta <emphasis>c�mo</emphasis> entregar la
+		  Documenta <emphasis>cómo</emphasis> entregar la
 		  memoria: unref, free, g_free, ...
 </para>
 	      </listitem>
 	    </itemizedlist>
 	  </listitem>
 	    <para>
 	      <emphasis>Se cuidadoso cuando uses copiar-y-pegar.</emphasis>
 </para>
 	    <para>
-			  El proceso de cortado y pegado no mejora el c�digo, al
+			  El proceso de cortado y pegado no mejora el código, al
 			  contrario de lo que creen muchos programadores.  Primero,
-			  mira el c�digo y si intenta producir muchas copias, quiz�s
+			  mira el código y si intenta producir muchas copias, quizás
-			  necesite una funci�n ayudante o nexo. <!-- FIXME: mejor
+			  necesite una función ayudante o nexo. <!-- FIXME: mejor
-			  traducci�n de helper -->
+			  traducción de helper -->
 </para>
 	  </listitem>
 <listitem>
 	    <para>
 	      <emphasis>Libera todo antes de salir.</emphasis>
 </para>
 <para>
-		  Esto lleva tiempo, as� que quiz�s debieras hacerlo
+		  Esto lleva tiempo, así que quizás debieras hacerlo
-		  s�lo dentro de una condici�n.
+		  sólo dentro de una condición.
 </para>
 	    <para>
 		  El motivo de este consejo es que los verificadores de memoria
-		  toman tiempo en determinar entre una p�rdida que tu conoces
+		  toman tiempo en determinar entre una pérdida que tu conoces
-		  y no te preocupan, y las otras p�rdidas.
+		  y no te preocupan, y las otras pérdidas.
 </para>
 	  </listitem>
 	  <listitem>
 	    <para>
 		  liberados a menos que vayas a liberar la estructura a la
 		  que pertenecen.
 </para>
 	    <para>
-		  Los punteros sueltos tienen la mala tendencia a ocultar p�rdidas
+		  Los punteros sueltos tienen la mala tendencia a ocultar pérdidas
 		  de memoria.
 	    </para>
 	  </listitem>
 	  <listitem>
 	    <para>
-	      <emphasis>Ejecuta el nuevo c�digo en un ciclo 1 mill�n de
+	      <emphasis>Ejecuta el nuevo código en un ciclo 1 millón de
 		  veces.</emphasis>
 </para>
 	    <para>
-		   Si pierdes memoria, lo sabr�s &mdash; s�lo sigue al proceso con
+		   Si pierdes memoria, lo sabrás &mdash; sólo sigue al proceso con
-		   <command>top</command> en otra ventana.  Podr�as querer
+		   <command>top</command> en otra ventana.  Podrías querer
 		   especificar a top el <symbol>PID</symbol>
-		   del proceso con la opci�n <parameter>-p</parameter>.
+		   del proceso con la opción <parameter>-p</parameter>.
 </para>
 	  </listitem>
 	  <listitem>
 	    <para>
-	      <emphasis>Rep�ralo ahora, no despu�s.</emphasis>
+	      <emphasis>Repáralo ahora, no después.</emphasis>
 </para>
 	    <para>
-		  No escribas una porquer�a de c�digo; m�s temprano que
+		  No escribas una porquería de código; más temprano que
-		  tarde te pesar�.
+		  tarde te pesará.
 </para>
 	  </listitem>
 	</itemizedlist>
 </para>
 </sect2>

changeset 6	4e44e6123b42
parent 5	4ca4c0227161
child 7	00ea2985a116