gnome-devel-docs master - en to es_ES translation catalogue (452 entries)

note: (itstool) path: info/desc
en: Other style guides and books about organizing free software projects
es_ES: Otros libros y guías de estilo sobre cómo organizar proyectos de software libre

note: (itstool) path: page/title
en: Additional Materials
es_ES: Material adicional

note: (itstool) path: page/p
en: Here we give you links to other materials that you may want to read. These will teach you a lot about how to work on large distributed teams of free software developers, and about good programming style in general.
es_ES: Aquí le damos enlaces a otros materiales que puede querer leer. Estos le enseñarán mucho sobre cómo trabajar en grandes equipos distribuidos de desarrolladores de software libre, y sobre el buen estilo de programación en general.

note: (itstool) path: item/p
en: <link href="http://producingoss.com/">Producing Open Source Software</link>, by Karl Fogel. This is a truly excellent book of good practices that free software projects should follow. This is about <em>social aspects</em> of the project: how to treat contributors, how to organize and moderate communication, how to deal with non-profit foundations. If you ask yourself at any time, "how should I deal with $human_situation in the project?", this book may provide the answer.
es_ES: <link href="http://producingoss.com/">Produducing Open Source Software</link>, de Karl Fogel. Éste realmente es un libro excelente de buenas prácticas que deberían seguir los proyectos de software libre. Esto es sobre <em>aspectos sociales</em> del proyecto: cómo tratar a los contribuidores, cómo organizar y moderar la comunicación, cómo tratar con las fundaciones sin ánimo de lucro. Si se pregunta alguna vez, «¿Cómo debería tratar con $human_situation en el proyecto?», este libro puede proporcionarle la respuesta.

note: (itstool) path: item/p
en: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. This is an old document, but it still has lots of excellent advice. It talks about C coding style, issues when dealing with plug-in systems, common option names for command-line programs, conventions for Makefiles, and some very GNU-ish details like using Texinfo for documentation.
es_ES: <link href="http://www.gnu.org/prep/standards/">GNU Coding Standards</link>. Éste es un viejo documento, pero aún tiene muchos consejos excelentes. Habla sobre estilo de programación C, problemas al tratar con sistemas enchufables, nombres de opciones comunes para programas de línea de comandos, convenciones para Makefiles y algunos detalles muy GNU-ish como el uso de Texinfo para la documentación.

note: (itstool) path: item/p
en: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst"> Linux Kernel Coding Style</link>. Explains the rationale for "big indentation", brace placement, concise but unambiguous naming, and centralized exit of functions.
es_ES: <link href="https://www.kernel.org/doc/Documentation/process/coding-style.rst">Linux Kernel Coding Style</link>. Explica la lógica de «la gran sangría», el lugar de las llaves, denominación concisa pero sin ambigüedades, y la salida centralizada de funciones.

note: (itstool) path: info/desc
en: Backwards compatibility in APIs
es_ES: Compatibilidad hacia atrás en API

note: (itstool) path: page/title
en: API stability
es_ES: Estabilidad de la API

note: (itstool) path: synopsis/title
en: Summary
es_ES: Resumen

note: (itstool) path: item/p
en: Define API stability guarantees for your project. (<link xref="#stability"/>)
es_ES: Define las garantías de estabilidad de la API para su proyecto. (<link xref='#stability'/>)

note: (itstool) path: item/p
en: Ensure version numbers are changed as appropriate when API changes. (<link xref="#versioning"/>)
es_ES: Asegúrese de que se cambian los números de versión adecuadamente cuando cambia la API. (<link xref='#versioning'/>)

note: (itstool) path: section/title
en: API and ABI
es_ES: API y ABI

note: (itstool) path: section/p
en: At a high level, an API – <em>Application Programming Interface</em> – is the boundary between two components when developing against them. It is closely related to an ABI – <em>Application Binary Interface</em> – which is the boundary at runtime. It defines the possible ways in which other components can interact with a component. More concretely, this normally means the C headers of a library form its API, and compiled library symbols its ABI. The difference between an API and ABI is given by compilation of the code: there are certain things in a C header, such as <code>#define</code>s, which can cause a library’s API to change without changing its ABI. But these differences are mostly academic, and for all practical purposes, API and ABI can be treated interchangeably.
es_ES: En un nivel superior, una API (<em>interfaz de programación de aplicaciones</em>) es el límite entre dos componentes cuando se desarrolla contra ellos. Está estrechamente relacionado con una ABI (<em>interfaz binaria de aplicación</em>) que es el límite en tiempo de ejecución. Define las posibles formas en que otros componentes pueden interactuar con un componente. Más concretamente, esto significa que normalmente las cabeceras C de una biblioteca forman su API, y los símbolos compilados de la biblioteca su ABI. La diferencia entre una API y ABI viene dada por la compilación del código: hay ciertas cosas en una cabecera C, como <code>#define</code>, que pueden causar cambiar la API de una biblioteca sin cambiar su ABI. Sin embargo, estas diferencias son en su mayoría académicas, y para todos los propósitos prácticos, la API y ABI se pueden tratar de manera intercambiable.

note: (itstool) path: section/p
en: Examples of API-incompatible changes to a C function would be to add a new parameter, change the function’s return type, or remove a parameter.
es_ES: Ejemplos de cambios API-incompatibles para una función C serían añadir un nuevo parámetro, cambiar el tipo de retorno de la función, o eliminar un parámetro.

note: (itstool) path: section/p
en: However, many other parts of a project can form an API. If a daemon exposes itself on D-Bus, the interfaces exported there form an API. Similarly, if a C API is exposed in higher level languages by use of GIR, the GIR file forms another API — if it changes, any higher level code using it must also change.
es_ES: Sin embargo, muchas otras partes de un proyecto pueden formar una API. Si un demonio se expone en D-Bus, las interfaces exportadas ahí forman una API. Del mismo modo, si una API en C se expone en lenguajes de alto nivel usando GIR, el archivo GIR forma otra API - si cambia, cualquier código de nivel superior que lo utilice también debe cambiar.

note: (itstool) path: section/p
en: Other examples of more unusual APIs are configuration file locations and formats, and GSettings schemas. Any changes to these could require code using your library to change.
es_ES: Otros ejemplos de API más inusuales son las ubicaciones del archivo de configuración y sus formatos, y esquemas GSettings. Cualquier cambio en estos podría requerir cambiar el código que usa su biblioteca.

note: (itstool) path: section/title
en: Stability
es_ES: Estabilidad

note: (itstool) path: section/p
en: API stability refers to some level of guarantee from a project that its API will only change in defined ways in the future, or will not change at all. Generally, an API is considered ‘stable’ if it commits to backwards-compatibility (defined below); but APIs could also commit to being unstable or even forwards-compatible. The purpose of API stability guarantees is to allow people to use your project from their own code without worrying about constantly updating their code to keep up with API changes. Typical API stability guarantees mean that code which is compiled against one version of a library will run without problems against all future versions of that library with the same major version number — or similarly that code which runs against a daemon will continue to run against all future versions of that daemon with the same major version number.
es_ES: La estabilidad de la API se refiere a un cierto nivel de garantía de un proyecto de que su API no cambiará en formas definidas en el futuro, o no cambiarán en absoluto. Generalmente, una API se considera «estable» si se compromete a la compatibilidad con versiones anteriores (definida más abajo); pero las API también podrían comprometerse a ser inestables o incluso compatibles hacia adelante. El propósito de las garantías de estabilidad de la API es permitir a la gente usar su proyecto desde su propio código sin preocuparse de actualizar constantemente su código para mantenerse actualizado con los cambios de la API. Normalmente la garantía de estabilidad de la API significa que el código que se compila contra una versión de una biblioteca funcionará sin problemas contra futuras versiones de esa biblioteca con el mismo número de versión principal — o de manera similar el código que funciona contra un demonio seguirá funcionando contra todas las futuras versiones de ese demonio con el mismo número de versión principal.

note: (itstool) path: section/p
en: It is possible to apply different levels of API stability to components within a project. For example, the core functions in a library could be stable, and hence their API left unchanged in future; while the newer, less core functions could be left unstable and allowed to change wildly until the right design is found, at which point they could be marked as stable.
es_ES: Es posible aplicar distintos niveles de estabilidad de API a los componentes dentro de un proyecto. Por ejemplo, las funciones del núcleo en una biblioteca podrían ser estables, y por lo tanto sus API dejarse sin cambios en el futuro; mientras las más nuevas, funciones menos relacionadas con el núcleo, podrían quedarse inestables y podrían cambiar incontroladamente hasta que se encuentra el diseño adecuado, momento en el que se podrían marcar como estables.

note: (itstool) path: section/p
en: Several types of stability commonly considered:
es_ES: Varios tipos de estabilidad comúnmente considerados:

note: (itstool) path: item/title
en: Unstable
es_ES: Inestable

note: (itstool) path: item/p
en: The API could change or be removed in future.
es_ES: La API puede cambiar o eliminarse en el futuro.

note: (itstool) path: item/title
en: Backwards compatible
es_ES: Compatibilidad hacia atrás

note: (itstool) path: item/p
en: Only changes which permit code compiled against the unmodified API to continue running against the modified API are allowed (for example, functions cannot be removed).
es_ES: Solo se permiten los cambios que permiten al código compilado contra la API no modificada continuar ejecutándose contra la API modificada (por ejemplo, no se pueden eliminar funciones).

note: (itstool) path: item/title
en: Forwards compatible
es_ES: Compatibilidad hacia adelante

note: (itstool) path: item/p
en: Only changes which permit code compiled against the modified API to run against the unmodified API are allowed (for example, functions cannot be added).
es_ES: Solo se permiten los cambios que permiten al código compilado contra la API modificada continuar ejecutándose contra la API no modificada (por ejemplo, no se pueden añadir funciones).

note: (itstool) path: item/title
en: Totally stable
es_ES: Totalmente estable

note: (itstool) path: item/p
en: No changes are allowed to the API, only to the implementation.
es_ES: No se permiten cambios en la API, sólo en la implementación.

note: (itstool) path: section/p
en: Typically, projects commit to backwards-compatibility when they say an API is ‘stable’. Very few projects commit to total stability because it would prevent almost all further development of the project.
es_ES: Normalmente, los proyecto se comprometen a la compatibilidad hacia atrás cuando dicen que una API es «estable». Muy pocos proyectos se comprometen a una estabilidad total porque eso frenaría casi todo desarrollo posterior del proyecto.

note: (itstool) path: section/title (itstool) path: page/title
en: Versioning
es_ES: Versionado

note: (itstool) path: section/p
en: API stability guarantees are strongly linked to project versioning; both package versioning and libtool versioning. Libtool versioning exists entirely for the purpose of tracking ABI stability, and is explained in detail on the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link> or <link xref="versioning"/>.
es_ES: Las garantías de estabilidad de la API están fuertemente vinculadas a las versiones del proyecto; ambas versiones del paquete y de libtool. El versionado libtool existe completamente con el propósito de trazar la estabilidad de la ABI, y se explica con detalle en <link href="https://autotools.io/libtool/version.htm">Autotools Mythbuster</link> o <link xref="versionin"/>.

note: (itstool) path: section/p
en: Package versioning (<em>major.minor.micro</em>) is strongly linked to API stability: typically, the major version number is incremented when backwards-incompatible changes are made (for example, when functions are renamed, parameters are changed, or functions are removed). The minor version number is incremented when forwards-incompatible changes are made (for example, when new public API is added). The micro version number is incremented when code changes are made without modifying API. See <link xref="versioning"/> for more information.
es_ES: El versionado de paquete (<em>major.minor.micro</em>) está fuertemente vinculado con la estabilidad de la API: normalmente, el número de la versión principal se incrementa cuando se hacen cambios incompatibles hacia atrás (por ejemplo, cuando se renombran funciones, se cambian parámetros, o se eliminan funciones). El número de versión secundaria se incrementa cuando se hacen cambios incompatibles hacia delante (piro ejemplo, cuando se añade una API pública nueva). El número de la micro versión se incrementa cuando se hacen cambios en el código sin modificar la API. Consulte la sección <link xref="versioning"/> para más información.

note: (itstool) path: section/p
en: API versioning is just as important for D-Bus APIs and GSettings schemas (if they are likely to change) as for C APIs. See the <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">documentation on D-Bus API versioning</link> for details.
es_ES: El versionado de las API es tan importante para las API D-Bus y esquemas GSettings (si es probable que cambien) como para las API C. Vea la <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">documentación en versionado de la API D-Bus</link> para más detalles.

note: (itstool) path: section/p
en: For GIR APIs, their stability typically follows the C API stability, as they are generated from the C API. One complexity is that their stability additionally depends on the version of gobject-introspection used in generating the GIR, but recent versions have not changed much so this is not a major concern.
es_ES: Para API GIR, su estabilidad normalmente sigue la estabilidad de la API C,  ya que se generan a partir de la API C. Una dificultad es que adicionalmente su estabilidad depende de la versión gobject-introspection usada al generar el GIR, pero las versiones recientes no han cambiado mucho por lo que no es una preocupación grande.

note: (itstool) path: section/title
en: External Links
es_ES: Enlaces externos

note: (itstool) path: section/p
en: The topic of API stability is covered in the following articles:
es_ES: El tema de la estabilidad de la API se trata en los siguientes artículos:

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_programming_interface">Wikipedia page on APIs</link>
es_ES: <link href="https://en.wikipedia.org/wiki/Application_programming_interface">Página de la Wikipedia sobre API</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Application_binary_interface">Wikipedia page on ABIs</link>
es_ES: <link href="https://en.wikipedia.org/wiki/Application_binary_interface">Página de la Wikipedia sobre ABI</link>

note: (itstool) path: item/p
en: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">D-Bus API versioning documentation</link>
es_ES: <link href="http://dbus.freedesktop.org/doc/dbus-api-design.html#api-versioning">Versionado de la documentación de la API de D-Bus</link>

note: (itstool) path: info/desc
en: Use of GLib-style asynchronous methods in various situations
es_ES: Uso de métodos asíncronos al estilo de GLib en varias situaciones

note: (itstool) path: page/title
en: Asynchronous Programming
es_ES: Programación asíncrona

note: (itstool) path: item/p
en: Use asynchronous calls in preference to synchronous calls or explicit use of threads (<link xref="#concepts"/>)
es_ES: Uso de llamadas asíncronas con preferencia a las llamadas síncronas o uso explícito de hilos (<link xref="#concepts"/>)

note: (itstool) path: item/p
en: Learn and follow the GLib pattern for declaring asynchronous APIs (<link xref="#api-pattern"/>)
es_ES: Aprenda y siga el patrón de GLib para declarar API asíncronas (<link xref="#api-pattern"/>)

note: (itstool) path: item/p
en: Place callbacks from asynchronous functions in order down the file, so control flow is easy to follow (<link xref="#single-call"/>)
es_ES: Coloque el retorno de llamadas de funciones asíncronas en orden descendente del archivo para que el control del flujo sea fácil de seguir (<link xref="#single-call"/>)

note: (itstool) path: item/p
en: Use the presence of a <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> or <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> to indicate whether an operation is ongoing (<link xref="#single-call"/>, <link xref="#gtask"/>)
es_ES: Use la presencia de un <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code></link> o <link href="https://developer.gnome.org/gio/stable/GCancellable.html"><code>GCancellable</code></link> para indicar si una operación está en curso (<link xref="#single-call"/>, <link xref="#gtask"/>)

note: (itstool) path: item/p
en: If running operations in parallel, track how many operations are yet to start, and how many are yet to finish — the overall operation is complete once both counts are zero (<link xref="#parallel"/>)
es_ES: Si ejecuta operaciones en paralelo, realice un seguimiento de cuántas operaciones aún deben comenzar y cuántas aún deben finalizar — la operación global se completa una vez que ambos recuentos son cero (<link xref="#parallel"/>)

note: (itstool) path: item/p
en: Separate state for operations into ‘task data’ structures for <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code>s</link>, allowing operations to be reused more easily without needing changes to global state handling (<link xref="#gtask"/>)
es_ES: Separe el estado de las operaciones en estructuras ‘task data’ para <link href="https://developer.gnome.org/gio/stable/GTask.html"><code>GTask</code>s</link>, permitiendo que se reutilicen las operaciones más fácilmente sin necesidad de cambios en la gestión del estado global (<link xref="#gtask"/>)

note: (itstool) path: item/p
en: Consider how asynchronous methods on an object instance interact with finalization of that instance (<link xref="#lifetimes"/>)
es_ES: Considere cómo los métodos asíncronos en una instancia de un objeto interactúan con la finalización de esa instancia (<link xref="#lifetimes"/>)

note: (itstool) path: section/title
en: Concepts
es_ES: Conceptos

note: (itstool) path: section/p
en: GLib supports <em>asynchronous</em> programming, where long-running operations can be started, run ‘in the background’, and a callback invoked when they are finished and their results are available. This is in direct contrast to <em>synchronous</em> long-running operations, which are a single function call which blocks program control flow until complete.
es_ES: GLib soporta programación <em>asíncrona</em>, donde se pueden iniciar operaciones de larga duración, ejecutarlas ‘en segundo plano’, e invocar un retorno de función cuando se completan y sus resultados están disponibles. Esto está en contraste directo con las operaciones de larga duración <em>asíncronas</em>, que son una única llamada de función que bloquea el control de flujo del programa hasta que se completa.

note: (itstool) path: section/p
en: As discussed in <link xref="main-contexts"/> and <link xref="threading#when-to-use-threading"/>, asynchronous operations should be favoured over synchronous ones and over explicit use of threading. They do not block the main context like sychronous operations do; and are easier to use correctly than threads. They often also have a lower performance penalty than spawning a thread and sending work to it.
es_ES: Como se discutió en <link xref="main-contexts"/> y <link xref="threading#when-to-use-threading"/>, las operaciones asíncronas deberían ser favorecidas sobre las síncronas y sobre el uso explícito de hilos. No bloquean el contexto principal como las operaciones síncronas y son más fáciles de utilizar correctamente que los hilos. Frecuentemente tienen una menor penalización en el rendimiento que generar un hilo y enviarle trabajo.

note: (itstool) path: section/title
en: API Pattern
es_ES: Patrón API

note: (itstool) path: section/p
en: Asynchronous calls follow a standard pattern in GLib code. For an operation named <code>load_data</code> on the <code>File</code> class in the <code>Foo</code> namespace, there will be:
es_ES: Las llamadas asíncronas siguen un patrón estándar en código GLib. Para una operación llamada <code>load_data</code> en la clase <code>File</code> en el espacio de nombres <code>Foo</code>, habrá:

note: (itstool) path: section/p
en: The <code>…</code> parameters to <code>foo_file_load_data_async()</code> are those specific to the operation — in this case, perhaps the size of a buffer to load into. Similarly for <code>foo_file_load_data_finish()</code> they are the operation-specific return values — perhaps a location to return a content type string in this case.
es_ES: Los parámetros <code>…</code> para <code>foo_file_load_data_async()</code> son los específicos para la operación, en este caso, quizá el tamaño de un búfer para cargar. De manera similar para <code>foo_file_load_data_finish()</code> son los valores de retorno específicos de la operación, quizá una ubicación para devolver una cadena de tipo de contenido en este caso.

note: (itstool) path: section/p
en: When <code>foo_file_load_data_async()</code> is called, it schedules the load operation in the background (as a new file descriptor on the <link xref="main-contexts"><code>GMainContext</code></link> or as a worker thread, for example), then returns without blocking.
es_ES: Cuando se llama a <code>foo_file_load_data_async()</code>, planifica la carga de la operación en segundo plano (como un nuevo descriptor de un archivo en el <link xref="main-contexts"><code>GMainContext</code></link> o como un nuevo hilo activo, por ejemplo), después vuelve sin bloquear.

note: (itstool) path: section/p
en: When the operation is complete, the <code>callback</code> is executed in the same <code>GMainContext</code> as the original asynchronous call. The callback is invoked <em>exactly</em> once, whether the operation succeeded or failed.
es_ES: Cuando se completa la operación, el <code>retorno de función</code> se ejecuta en el mismo <code>GMainContext</code> que la llamada asíncrona original. El retorno de función se invoca <em>exactamente</em> una vez, tanto si la operación concluyó con éxito como si concluyó con error.

note: (itstool) path: section/p
en: From the callback, <code>foo_file_load_data_finish()</code> may be called by the user’s code to retrieve return values and error details, passing the <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html"><code>GAsyncResult</code></link> instance which was passed to the callback.
es_ES: Desde el retorno de llamada <code>foo_file_data_finish()</code> se puede llamar por el código del usuario para obtener valores de retorno y detalles de error, pasando la instancia <link href="https://developer.gnome.org/gio/stable/GAsyncResult.html"><code>GAsyncResult</code></link> que se pasó al retorno de llamada.

note: (itstool) path: section/title
en: Operation Lifetimes
es_ES: Tiempos de vida de la operación

note: (itstool) path: section/p
en: When writing asynchronous operations, it is common to write them as methods of a class. In this case, it is important to define how ongoing operations on a class instance interact with finalization of that instance. There are two approaches:
es_ES: Al escribir operaciones asíncronas, es común escribirlas como métodos de una clase. En este caso, es importante definir cómo las operaciones en curso en una instancia de clase interactúan con la finalización de esa instancia. Hay dos enfoques:

note: (itstool) path: item/title
en: Strong
es_ES: Fuerte

note: (itstool) path: item/p
en: The ongoing operation keeps a reference to the class instance, forcing it to remain alive for the duration of the operation. The class should provide some kind of ‘close’ or ‘cancel’ method which can be used by other classes to force cancellation of the operation and allow that instance to be finalized.
es_ES: La operación en curso mantiene una referencia a la instancia de clase, forzándola a permanecer viva mientras dure la operación. La clase debe proporcionar algún tipo de método de «cierre» o «cancelación» que otras clases puedan utilizar para forzar la cancelación de la operación y permitir que se finalice esa instancia.

note: (itstool) path: item/title
en: Weak
es_ES: Débil

note: (itstool) path: item/p
en: The ongoing operation does <em>not</em> keep a reference to the class instance, and the class cancels the operation (using <link href="https://developer.gnome.org/gio/stable/GCancellable.html#g-cancellable-cancel"><code>g_cancellable_cancel()</code></link>) in its dispose function.
es_ES: La operación en curso <em>no</em> mantiene una referencia a la instancia de la clase, y la clase cancela la operación (usando <link href="https://developer.gnome.org/gio/stable/GCancellable.html#g-cancellable-cancel"><code>g_cancellable_cancel()</code></link>) en su función de disposición.

note: (itstool) path: section/title
en: Examples of Using Asynchronous Functions
es_ES: Ejemplos de uso de funciones asíncronas

note: (itstool) path: section/title
en: Single Operation
es_ES: Operación individual

note: (itstool) path: section/p
en: A single asynchronous call requires two functions: one to start the operation, and one to complete it. In C, the demanding part of performing an asynchronous call is correctly storing state between these two functions, and handling changes to that state in the time between those two functions being called. For example, cancellation of an ongoing asynchronous call is a state change, and if not implemented carefully, any UI updates (for example) made when cancelling an operation will be undone by updates in the operation’s callback.
es_ES: Una sola llamada asincrónica requiere dos funciones: una para iniciar la operación y otra para completarla. En C, la parte exigente de ejecarut una llamada asíncrona es almacenar correctamente el estado entre estas dos funciones y manejar los cambios a ese estado en el tiempo entre esas dos funciones que se están llamando. Por ejemplo, la cancelación de una llamada asíncrona en curso es un cambio de estado, y si no se implementa con cuidado, algunas actualizaciones de la IU (por ejemplo) realizadas al cancelar una operación serán deshechas por las actualizaciones en el retorno de llamada de la operación.

note: (itstool) path: example/p
en: This example demonstrates copying a file from one location in the file system to another. The key principles demonstrated here are:
es_ES: Este ejemplo muestra cómo copiar un archivo de una ubicación en el sistema de archivos a otra. Los principios clave demostrados aquí son:

note: (itstool) path: section/title
en: Operations in Series
es_ES: Operaciones en serie

note: (itstool) path: section/p
en: A common situation is to run multiple asynchronous operations in series, when each operation depends on the previous one completing.
es_ES: Una situación común es ejecutar múltiples operaciones asincrónicas en serie, cuando cada operación depende de que se complete la anterior.

note: (itstool) path: example/p
en: In this example, the application reads a socket address from a file, opens a connection to that address, reads a message, and then finishes.
es_ES: En este ejemplo, la aplicación lee una dirección de socket desde un archivo, abre una conexión a esa dirección, lee un mensaje y luego termina.

note: (itstool) path: example/p
en: Key points in this example are:
es_ES: Los puntos clave en este ejemplo son:

note: (itstool) path: item/p
en: Each callback is numbered consistently, and they are all placed in order in the file so the code follows sequentially.
es_ES: Cada retorno de llamada es numerada consistentemente y están todas colocadas en orden en el archivo para que el código siga secuencialmente.

note: (itstool) path: item/p
en: As in <link xref="#single-call"/>, a single <code>GCancellable</code> indicates that the series of operations is ongoing. Cancelling it aborts the entire sequence.
es_ES: Como en <link xref="#single-call"/>, un único <code>GCancellable</code> indica que la serie de operaciones está en curso. Al cancelarlo se aborta toda la secuencia.

note: (itstool) path: item/p
en: As in <link xref="#single-call"/>, the pending operation is cancelled if the owning <code>MyObject</code> instance is disposed, to prevent callbacks being called later with an invalid <code>MyObject</code> pointer.
es_ES: Como en <link xref="#single-call"/>, la operación pendiente se cancela si se elimina la instancia propietaria de <code>MyObject</code> para evitar que se llame a los retornos de función después con un puntero a <code>MyObject</code> no válido.

note: (itstool) path: section/title
en: Operations in Parallel
es_ES: Operaciones en paralelo

note: (itstool) path: section/p
en: Another common situation is to run multiple asynchronous operations in parallel, considering the overall operation complete when all its constituents are complete.
es_ES: Otra situación común es ejecutar múltiples operaciones asincrónicas en paralelo, considerando que la operación general se completa cuando todos sus componentes están completos.

note: (itstool) path: example/p
en: In this example, the application deletes multiple files in parallel.
es_ES: En este ejemplo, la aplicación elimina varios archivos en paralelo.

note: (itstool) path: section/title
en: Wrapping with <code>GTask</code>
es_ES: Envoltorio con <code>GTask</code>

note: (itstool) path: credit/name
en: The GTK+ Team
es_ES: El equipo de GTK+

note: (itstool) path: info/desc
en: Our guidelines for C code in GNOME
es_ES: Nuestras directrices para el código C en GNOME

note: (itstool) path: page/title
en: C Coding Style
es_ES: Estilo de codificación en C

note: (itstool) path: page/p
en: This document presents the preferred coding style for C programs in GNOME. While coding style is very much a matter of taste, in GNOME we favor a coding style that promotes consistency, readability, and maintainability.
es_ES: Este documento presenta el estilo de codificación preferido para los programas en C en GNOME. Mientras que el estilo de codificación es en gran medida una cuestión de gustos, en GNOME estamos a favor de un estilo de codificación que promueve la consistencia, legibilidad y mantenibilidad.

note: (itstool) path: page/p
en: We present examples of good coding style as well as examples of bad style that is not acceptable in GNOME. Please try to submit patches that conform to GNOME’s coding style; this indicates that you have done your homework to respect the project’s goal of long-term maintainability. Patches with GNOME’s coding style will also be easier to review!
es_ES: Presentamos ejemplos de buen estilo de codificación así como ejemplos de mal estilo que no es aceptable en GNOME. Intente enviar parches que se ajusten al estilo de codificación de GNOME; esto indica que ha hecho sus deberes respecto al objetivo del proyecto de mantenibilidad a largo plazo. ¡Los parches con el estilo de codificación de GNOME serán también más fáciles de revisar!

note: (itstool) path: note/p
en: This document is for C code. For other languages, check the <link xref="index">main page</link> of the GNOME Programming Guidelines.
es_ES: Este documento es para código C. Para otros lenguajes, compruebe la <link xref="índex">página principal</link> de las directrices de programación de GNOME.

note: (itstool) path: page/p
en: These guidelines are heavily inspired by GTK’s CODING-STYLE document, the Linux Kernel’s CodingStyle, and the GNU Coding Standards. These are slight variations of each other, with particular modifications for each project’s particular needs and culture, and GNOME’s version is no different.
es_ES: Estas directrices están fuertemente inspiradas por el documento GTK’s CODING STYLE, el Linux Kernel’s CodingStyle, y el GNU Coding Standards. Estos son pequeñas variaciones cada uno de otro, con modificaciones particulares para las necesidades y cultura particulares de cada proyecto, y la versión de GNOME no es diferente.

note: (itstool) path: section/title
en: The Single Most Important Rule
es_ES: La única regla más importante

note: (itstool) path: section/p
en: The single most important rule when writing code is this: <em>check the surrounding code and try to imitate it</em>.
es_ES: La única regla más importante al escribir código es: <em>revise el código existente y trate de imitarlo</em>.

note: (itstool) path: section/p
en: As a maintainer it is dismaying to receive a patch that is obviously in a different coding style to the surrounding code. This is disrespectful, like someone tromping into a spotlessly-clean house with muddy shoes.
es_ES: Como mantenedor es desalentador recibir un parche que está obviamente en un estilo de codificación diferente al código ya existente. Esto es una falta de respeto, como cuando alguien pisa en una casa impecablemente limpia con los zapatos llenos de barro.

note: (itstool) path: section/p
en: So, whatever this document recommends, if there is already written code and you are patching it, keep its current style consistent even if it is not your favorite style.
es_ES: Por lo tanto, sea lo que sea lo que este documento recomienda, si ya hay código y lo está parcheando, mantenga su estilo actual coherente incluso si no es su estilo favorito.

note: (itstool) path: section/title
en: Line Width
es_ES: Anchura de línea

note: (itstool) path: section/p
en: Try to use lines of code between 80 and 120 characters long. This amount of text is easy to fit in most monitors with a decent font size. Lines longer than that become hard to read, and they mean that you should probably restructure your code. If you have too many levels of indentation, it means that you should fix your code anyway.
es_ES: Intente usar líneas de código de entre 80 y 120 caracteres de largo. Esta cantidad de texto es fácil de ajustar en la mayoría de monitores con un tamaño de tipografía decente. Las líneas más largas se vuelve difíciles de leer, y significan que probablemente debería reestructurar su código. Si tiene demasiados niveles de sangrado, significa que debería arreglar su código de alguna manera.

note: (itstool) path: section/title
en: Indentation
es_ES: Sangrado

note: (itstool) path: section/p
en: In general there are two preferred indentation styles for code in GNOME.
es_ES: En general hay dos estilos de sangrado preferidos para el código en GNOME.

note: (itstool) path: item/p
en: Linux Kernel style. Tabs with a length of 8 characters are used for the indentation, with K&amp;R brace placement:
es_ES: Estilo del kernel de Linux. Los tabuladores con una longitud de 8 caracteres se usan para el sangrado, con K&amp;R el lugar de las llaves:

note: (itstool) path: item/p
en: GNU style. Each new level is indented by 2 spaces, braces go on a line by themselves, and they are indented as well.
es_ES: Estilo GNU. Cada nuevo nivel se sangra con dos espacios, las llaves van en una línea solas, y se sangran también.

note: (itstool) path: section/p
en: Both styles have their pros and cons. The most important things is to <em>be consistent</em> with the surrounding code. For example, the GTK+ library, which is GNOME’s widget toolkit, is written with the GNU style. Nautilus, GNOME’s file manager, is written in Linux kernel style. Both styles are perfectly readable and consistent when you get used to them.
es_ES: Ambos estilos tienen sus pros y contras. Lo más importante es <em>ser coherente</em> con el código existente. Por ejemplo, la biblioteca GTK+, que es el kit de herramientas para widgets de GNOME, está escrita con el estilo GNU. Nautilus, el gestor de archivos de GNOME, está escrito con el estilo del kernel de Linux. Ambos estilos son perfectamente legibles y coherentes cuando se acostumbra a ellos.

note: (itstool) path: section/title
en: Tab Characters
es_ES: Tabuladores

note: (itstool) path: section/p
en: <em>Do not ever change the size of tabs in your editor</em>; leave them as 8 spaces. Changing the size of tabs means that code that you didn’t write yourself will be perpetually misaligned.
es_ES: <em>Nunca cambie el tamaño de los tabuladores en su editor</em>; déjelos con 8 espacios. Cambiar el tamaño de los tabuladores significa que el código que no escribió estará perpetuamente mal alineado.

note: (itstool) path: section/p
en: Instead, set the <em>indentation size</em> as appropriate for the code you are editing. When writing in something other than Linux kernel style, you may even want to tell your editor to automatically convert all tabs to 8 spaces, so that there is no ambiguity about the intended amount of space.
es_ES: En su lugar, configure el <em>tamaño de sangría</em> según corresponda para el código que está editando. Al escribir en algo que no sea el estilo del kernel de Linux, incluso puede pedirle a su editor que convierta automáticamente todos los tabuladores a 8 espacios, para que no haya ambigüedad sobre la cantidad de espacio prevista.

note: (itstool) path: section/title
en: Braces
es_ES: Paréntesis

note: (itstool) path: section/p
en: Curly braces should not be used for single statement blocks:
es_ES: Las llaves no deberían usarse para bloques de una sola sentencia:

note: (itstool) path: section/p
en: The “no block for single statements” rule has only four exceptions:
es_ES: La regla «sin bloqueo para declaraciones únicas» tiene solo cuatro excepciones:

note: (itstool) path: item/p
en: If the condition is composed of many lines:
es_ES: Si la condición se compone de varias líneas:

note: (itstool) path: section/p
en: In general, new blocks should be placed on a new indentation level, like this:
es_ES: En general, los bloques nuevos se deben colocar con un nivel de sangrado nuevo, como esto:

note: (itstool) path: section/p
en: While curly braces for function definitions should rest on a new line they should not add an indentation level:
es_ES: Si bien las llaves para las definiciones de funciones deben descansar en una nueva línea, no deben agregar un nivel de sangría:

note: (itstool) path: section/title
en: Conditions
es_ES: Condiciones

note: (itstool) path: section/title
en: Functions
es_ES: Funciones

note: (itstool) path: section/p
en: Functions should be declared by placing the returned value on a separate line from the function name:
es_ES: Las funciones se deben declarar colocando el valor devuelto en una línea separada del nombre de la función:

note: (itstool) path: section/p
en: The argument list must be broken into a new line for each argument, with the argument names right aligned, taking into account pointers:
es_ES: La lista de argumentos debe dividirse en una nueva línea para cada argumento, con los nombres de los argumentos alineados a la derecha, teniendo en cuenta los punteros:

note: (itstool) path: section/p
en: The alignment also holds when invoking a function without breaking the line length limit:
es_ES: La alineación también se mantiene cuando se invoca una función sin romper el límite de longitud de línea:

note: (itstool) path: section/code
en: 
    align_function_arguments (first_argument,
                              second_argument,
                              third_argument);
es_ES: 
    alinear_argumentos_funciones (primer_argumento,
                              segundo_argumento,
                              tercer_argumento);

note: (itstool) path: section/title
en: Whitespace
es_ES: Espacio en blanco

note: (itstool) path: section/p
en: Always put a space before an opening parenthesis but never after:
es_ES: Ponga siempre un espacio antes de abrir un paréntesis, pero nunca después:

note: (itstool) path: section/p
en: When declaring a structure type use newlines to separate logical sections of the structure:
es_ES: Al declarar un tipo de estructura, utilice líneas nuevas para separar secciones lógicas de la estructura:

note: (itstool) path: section/p
en: Do not eliminate whitespace and newlines just because something would fit on a single line:
es_ES: No elimine espacios en blanco y saltos de línea simplemente porque algo quepa en una única línea:

note: (itstool) path: section/p
en: Do eliminate trailing whitespace on any line, preferably as a separate patch or commit. Never use empty lines at the beginning or at the end of a file.
es_ES: Elimine los espacios en blanco finales en cualquier línea, preferiblemente como un parche o confirmación por separado. Nunca use líneas vacías al principio o al final de un archivo.

note: (itstool) path: section/p
en: This is a little Emacs function that you can use to clean up lines with trailing whitespace:
es_ES: Esta es una pequeña función de Emacs que puede usar para limpiar líneas con espacios en blanco al final:

note: (itstool) path: section/title
en: The <code>switch</code> Statement
es_ES: La sentencia <code>switch</code>

note: (itstool) path: section/p
en: It is preferable, though not mandatory, to separate the various cases with a newline:
es_ES: Es preferible, pero no obligatorio, separar los distintos casos con un salto de línea:

note: (itstool) path: section/p
en: The <code>break</code> statement for the <code>default</code> case is not mandatory.
es_ES: La sentencia <code>break</code> para el caso <code>default</code> no es obligatoria.

note: (itstool) path: section/title
en: Header Files
es_ES: Archivos de cabecera

note: (itstool) path: section/p
en: The only major rule for headers is that the function definitions should be vertically aligned in three columns:
es_ES: La única regla principal para los encabezados es que las definiciones de funciones deben alinearse verticalmente en tres columnas:

note: (itstool) path: section/p
en: The maximum width of each column is given by the longest element in the column:
es_ES: La anchura máxima de cada columna viene dada por el elemento más largo de la columna:

note: (itstool) path: section/p
en: It is also possible to align the columns to the next tab:
es_ES: También es posible alinear las columnas al siguiente tabulador:

note: (itstool) path: section/title
en: GObject Classes
es_ES: Clases de GObject

note: (itstool) path: section/p
en: Typedef declarations should be placed at the beginning of the file:
es_ES: Las declaraciones «typedef» se deben colocar al principio del archivo:

note: (itstool) path: section/p
en: This includes enumeration types:
es_ES: Esto incluye los tipos enumerados:

note: (itstool) path: section/p
en: And callback types:
es_ES: Y los tipos de retornos de llamadas:

note: (itstool) path: section/p
en: Instance structures should be declared using <code>G_DECLARE_FINAL_TYPE</code> or <code>G_DECLARE_DERIVABLE_TYPE</code>:
es_ES: Las instancias de estructuras se deben declarar usando <code>G_DECLARE_FINAL_TYPE</code> o <code>G_DECLARE_DERIVABLE_TYPE</code>:

note: (itstool) path: section/p
en: For final types, private data can be stored in the object struct, which should be defined in the C file:
es_ES: Para los tipos finales, los datos privados se pueden almacenar en la estructura del objeto, que se debe definir en el archivo C:

note: (itstool) path: section/p
en: Interface types should always have the dummy typedef for cast purposes:
es_ES: Los tipos de interfaz siempre deben tener el tipo de definición ficticio para propósitos de conversión:

note: (itstool) path: section/p
en: Interfaces must have the following macros:
es_ES: Las interfaces deben tener las siguientes macros:

note: (itstool) path: td/p
en: Expands to
es_ES: Se expande a

note: (itstool) path: section/title
en: Memory Allocation
es_ES: Reserva de memoria

note: (itstool) path: section/p
en: See <link xref="memory-management"/> for more details.
es_ES: Consulte la sección <link xref="memory-management"/> para obtener más detalles.

note: (itstool) path: section/p
en: Inline functions are usually preferable to private macros.
es_ES: Normalmente, se prefieren las funciones en línea a las macros privadas.

note: (itstool) path: section/p
en: Public macros should not be used unless they evaluate to a constant.
es_ES: Las macros públicas no deben usarse a menos que se evalúen como una constante.

note: (itstool) path: section/title
en: Public API
es_ES: API pública

note: (itstool) path: section/p
en: Avoid exporting variables as public API, since this is cumbersome on some platforms. It is always preferable to add getters and setters instead. Also, beware global variables in general.
es_ES: Evite exportar variables como API públicas, ya que esto es engorroso en algunas plataformas. Siempre es preferible agregar «getters» y «setters» en su lugar. También tenga cuidado con las variables globales en general.

note: (itstool) path: section/title
en: Private API
es_ES: API privada

note: (itstool) path: section/p
en: Underscore-prefixed functions are never exported.
es_ES: Las funciones con un guión bajo al principio nunca se exportan.

note: (itstool) path: license/p
en: This work is licensed under a <_:link-1/>.
es_ES: Este trabajo está licenciado bajo la <_:link-1/>.

note: (itstool) path: page/title
en: Databases
es_ES: Bases de datos

note: (itstool) path: section/title
en: When to Use Databases
es_ES: Cuándo usar bases de datos

note: (itstool) path: section/p
en: Configuration data should be stored in <link href="https://developer.gnome.org/gio/stable/GSettings.html">GSettings</link>. As a rule of thumb, if some data needs to be persistent and affects how an application behaves, it is configuration data. If it could potentially be subject to policies imposed by the system administrator (such as proxy or lockdown settings), it is configuration data. If it contains user created content, it is not configuration data, and should not be stored in GSettings.
es_ES: Los datos de configuración deben almacenarse en <link href="https://developer.gnome.org/gio/stable/GSettings.html"> GSettings </link>. Como regla general, si algunos datos deben ser persistentes y afectan el comportamiento de una aplicación, son datos de configuración. Si podría estar sujeto a políticas impuestas por el administrador del sistema (como la configuración de proxy o de bloqueo), son datos de configuración. Si contiene contenido creado por el usuario, no son datos de configuración y no deben almacenarse en GSettings.

note: (itstool) path: section/p
en: GOM should be used if you need advanced features, especially indexing. GVDB should be used otherwise.
es_ES: GOM debe usarse si necesita funciones avanzadas, especialmente indexación. En otros casos debe usarse GVDB.

note: (itstool) path: section/title
en: Using GOM
es_ES: Usar GOM

note: (itstool) path: section/title
en: SQL Injection
es_ES: Inyección SQL

note: (itstool) path: section/title
en: Using GVDB
es_ES: Usar GVDB

note: (itstool) path: section/p
en: A full GVDB tutorial is beyond the scope of this document.
es_ES: Un manual completo de GVDB está fuera del alcance de este documento.

note: (itstool) path: info/desc
en: Adding documentation to libraries and APIs
es_ES: Añadir documentación para bibliotecas y API

note: (itstool) path: page/title (itstool) path: section/title
en: Documentation
es_ES: Documentación

note: (itstool) path: item/p
en: Use gtk-doc with up-to-date settings for API documentation. (<link xref="#gtk-doc"/>)
es_ES: Use gtk-doc con una configuración actualizada para la documentación de la API. (Consulte la sección <link xref="#gtk-doc"/>)

note: (itstool) path: item/p
en: Use <cmd>gdbus-codegen</cmd> to generate D-Bus API documentation to include in the gtk-doc build. (<link xref="#dbus-api"/>)
es_ES: Use <cmd>gdbus-codegen</cmd> para generar la documentación de la API de D-Bus que incluir en la construcción de gtk-doc. (Consulte la sección <link xref="#dbus-api"/>)

note: (itstool) path: item/p
en: Add introspection annotations to all API documentation. (<link xref="#introspection-annotations"/>)
es_ES: Añada anotaciones de instrospección a toda la documentación de la API. (Consulte la sección <link xref="#introspection-annotations"/>)

note: (itstool) path: item/p
en: Enable gtk-doc tests. (<link xref="#keeping-up-to-date"/>)
es_ES: Activar las pruebas de gtk-doc. (<link xref="#keeping-up-to-date"/>)

note: (itstool) path: section/title
en: Build System
es_ES: Sistema de construcción

note: (itstool) path: section/title
en: Standard Layout
es_ES: Distribución estándar

note: (itstool) path: section/p
en: The following layout is suggested:
es_ES: Se sugiere la siguiente distribución:

note: (itstool) path: listing/title
en: <file><var>project-name</var>-docs.xml</file>
es_ES: <file><var>nombre-proyecto</var>-docs.xml</file>

note: (itstool) path: section/title
en: Licensing
es_ES: Licencia

note: (itstool) path: section/p
en: It is important to make the license used for API references clear, especially if they contain code examples which could be copied around.
es_ES: Es importante aclarar la licencia utilizada para las referencias API, especialmente si contienen ejemplos de código que podrían copiarse.

note: (itstool) path: section/title
en: Public APIs
es_ES: API públicas

note: (itstool) path: section/p
en: All public APIs must have gtk-doc comments. For functions, these should be placed in the source file, directly above the function.
es_ES: Todas las API públicas deben tener comentarios de tipo gtk-doc. Para las funciones, estos se deben colocar en el código fuente, encima de la función.

note: (itstool) path: section/p
en: Documentation comments for macros, function types, class structs, etc. should be placed next to the definitions, typically in header files.
es_ES: Los comentarios de documentación para macros, tipos de funciones, estructuras de clase, etc. deben colocarse junto a las definiciones, generalmente en archivos de encabezado.

note: (itstool) path: section/p
en: Section introductions should be placed in the source file they describe, after the license header:
es_ES: Las introducciones de la sección deben colocarse en el archivo fuente que describen, después del encabezado de la licencia:

note: (itstool) path: section/title
en: Introspection Annotations
es_ES: Anotaciones de instrospección

note: (itstool) path: item/p
en: They add important information about parameter types, nullability and memory management to the C API documentation generated by gtk-doc.
es_ES: Añaden información importante sobre los tipos de parámetros, la nulabilidad y la administración de memoria a la documentación de la API C generada por gtk-doc.

note: (itstool) path: item/p
en: They allow public APIs to be automatically bound in other languages, such as Python or JavaScript.
es_ES: Permiten que las API públicas se vinculen automáticamente en otros lenguajes, como Python o JavaScript.

note: (itstool) path: section/p
en: Introspection annotations add information to APIs (functions, function parameters, function return values, structures, GObject properties, GObject signals) which is otherwise not present in the machine readable C API and only exists in the form of human readable documentation or convention. They are very important.
es_ES: Las anotaciones de introspección agregan información a las API (funciones, parámetros de función, valores de retorno de función, estructuras, propiedades de GObject, señales de GObject) que de otro modo no está presente en la API de C legible por máquina y solo existe en forma de documentación o convenio legible por humanos. Son muy importantes.

note: (itstool) path: section/p
en: Instead of:
es_ES: En lugar de:

note: (itstool) path: section/title
en: Symbol Versioning
es_ES: Versionado de símbolos

note: (itstool) path: section/p (itstool) path: example/p
en: For example:
es_ES: Por ejemplo:

note: (itstool) path: section/title
en: D-Bus APIs
es_ES: API de D-Bus

note: (itstool) path: section/title
en: Keeping Documentation Up to Date
es_ES: Mantener la documentación actualizada

note: (itstool) path: section/p
en: They will then be run as part of <cmd>make check</cmd>.
es_ES: Se ejecutarán como parte de <cmd>make check</cmd>.

note: (itstool) path: info/desc
en: Accessing the file system
es_ES: Acceder al sistema de archivos

note: (itstool) path: page/title
en: File System Access
es_ES: Acceso al sistema de archivos

note: (itstool) path: item/p
en: Use asynchronous I/O for file access. (<link xref="#asynchronous-io"/>)
es_ES: Use E/S asíncrona para acceder a archivos. (Consulte la sección <link xref="#asynchronous-io"/>)

note: (itstool) path: section/title
en: Asynchronous I/O
es_ES: E/S asíncrona

note: (itstool) path: example/p
en: For example, <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read-async"><code>g_input_stream_read_async()</code></link> rather than <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read"><code>g_input_stream_read()</code></link>.
es_ES: Por ejempl, <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read-async"><code>g_input_stream_read_async()</code></link> en lugar de <link href="https://developer.gnome.org/gio/stable/GInputStream.html#g-input-stream-read"><code>g_input_stream_read()</code></link>.

note: (itstool) path: section/p
en: Synchronous I/O blocks the main loop, which means that other events, such as user input, incoming networking packets, timeouts and idle callbacks, are not handled until the blocking function returns.
es_ES: La E / S síncrona bloquea el bucle principal, lo que significa que otros eventos, como la entrada del usuario, los paquetes de red entrantes, los tiempos de espera y las devoluciones de llamadas inactivas, no se manejan hasta que vuelve la función de bloqueo.

note: (itstool) path: section/title
en: File Path Construction
es_ES: Construcción de rutas de archivos

note: (itstool) path: info/desc
en: Runtime error handling and reporting
es_ES: Manejo y reporte de errores en tiempo de ejecución

note: (itstool) path: section/title
en: GError Usage
es_ES: Uso de GError

note: (itstool) path: section/p
en: The GLib API documentation contains a <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#glib-Error-Reporting.description">full tutorial for using GError</link>.
es_ES: La documentación de la API de GLib contiene un <link href="https://developer.gnome.org/glib/stable/glib-Error-Reporting.html#glib-Error-Reporting.description">tutorial completo sobre el uso de GError</link>.

note: (itstool) path: info/desc
en: Linked lists and container types
es_ES: Listas enlazadas y tipos de contenedores

note: (itstool) path: section/title
en: GList Usage
es_ES: Uso de GList

note: (itstool) path: section/p
en: Implementing the above with a GPtrArray has the same complexity as the first (correct) GList implementation, but better cache locality and lower memory consumption, so will perform better for large numbers of elements:
es_ES: La implementación de lo anterior con un GPtrArray tiene la misma complejidad que la primera implementación GList (correcta), pero mejor localidad de caché y menor consumo de memoria, por lo que funcionará mejor para un gran número de elementos:

note: (itstool) path: credit/name
en: GNOME Foundation
es_ES: Fundación GNOME

note: (itstool) path: info/desc (itstool) path: page/title
en: GNOME Programming Guidelines
es_ES: Guías de programación de GNOME

[ctx: link:trail]
note: (itstool) path: info/title
en: Programming Guidelines
es_ES: Guías de programación

note: (itstool) path: page/p
en: This article contains several guidelines and suggestions for programmers working in and with the GNOME stack. This is intended for programmers to know about the development processes, conventions and philosophies behind GNOME applications and the stack of libraries supporting them. By knowing “the way things are done” in the GNOME ecosystem, it is hoped that programmers will find use of GNOME APIs and development of new applications easier and more natural, and will produce code which is legible and maintainable over a long period of time by a diverse team of programmers.
es_ES: Este artículo contiene varias pautas y sugerencias para los programadores que trabajan en y con la pila de GNOME. Esto está destinado a que los programadores conozcan los procesos de desarrollo, las convenciones y las filosofías detrás de las aplicaciones de GNOME y la pila de bibliotecas que las respaldan. Al conocer «cómo se hacen las cosas» en el ecosistema de GNOME, se espera que los programadores encuentren el uso de las API de GNOME y el desarrollo de nuevas aplicaciones más fáciles y más naturales, y produzcan código que sea legible y mantenible durante un largo período de tiempo por un equipo diverso de programadores.e copiado alrededor.

note: (itstool) path: page/p
en: This guide has a two-fold purpose:
es_ES: Esta guía tiene un doble propósito:

note: (itstool) path: item/p
en: To give you good suggestions on how to write code for GNOME or using GNOME technologies. This will help you write code that is consistent with best practices, and that will be accepted by the community. This will also lead to code that is a pleasure to work on.
es_ES: Para darle buenas sugerencias sobre cómo escribir código para GNOME o usar las tecnologías de GNOME. Esto lo ayudará a escribir código que sea consistente con las mejores prácticas, y que será aceptado por la comunidad. Esto también conducirá a un código en el que es un placer trabajar.

note: (itstool) path: item/p
en: To transmit the knowledge we have gotten over the years on how to keep the GNOME project sustainable, even when people’s contributions increase or decrease.
es_ES: Para transmitir el conocimiento que hemos obtenido a lo largo de los años sobre cómo mantener el proyecto GNOME sostenible, incluso cuando las contribuciones de las personas aumentan o disminuyen.

[ctx: link:trail]
note: (itstool) path: info/title
en: General Guidelines
es_ES: Guías generales

note: (itstool) path: section/title
en: General Guidelines
es_ES: Guías generales

[ctx: link:trail]
note: (itstool) path: info/title
en: Maintainer Guidelines
es_ES: Guías del mantenedor

note: (itstool) path: section/title
en: Maintainer Guidelines
es_ES: Guías del mantenedor

[ctx: link:trail]
note: (itstool) path: info/title
en: Specific How-Tos
es_ES: Guías específicas

note: (itstool) path: section/title
en: Specific How-Tos
es_ES: Guías específicas

[ctx: link:trail]
note: (itstool) path: info/title
en: References
es_ES: Referencias

note: (itstool) path: section/title
en: References
es_ES: Referencias

note: (itstool) path: info/desc
en: GObject Introspection support in library code
es_ES: Soporte de introspección GObject en código de biblioteca

note: (itstool) path: page/title
en: Introspection
es_ES: Introspección

note: (itstool) path: item/p
en: Enable introspection for all libraries. (<link xref="#using-introspection"/>)
es_ES: Active la introspección para todas las bibliotecas. (Consulte la sección <link xref="#using-introspection"/>)

note: (itstool) path: section/title
en: Using Introspection
es_ES: Usar la introspección

note: (itstool) path: section/title
en: API Design
es_ES: Diseño de la API

note: (itstool) path: info/desc
en: Logging debug and information output from libraries and programs
es_ES: Registro de depuración y salida de información de bibliotecas y programas

note: (itstool) path: page/title
en: Logging
es_ES: Registro

note: (itstool) path: synopsis/p
en: Logging debug and informational output from libraries and programs is an open problem, and there are various methods for converting multiple streams of log output into the customary stdout and stderr streams. Below are some suggestions for how to implement logging. However, the most important thing is to ensure that logging is consistent, so that log data can be accessed and searched with a minimum of effort, since that’s what it’s used for. Using different logging mechanisms and formats in different projects is not the right approach.
es_ES: El registro de la depuración y la salida informativa de bibliotecas y programas es un problema abierto, y existen varios métodos para convertir múltiples flujos de salida de registro en los flujos stdout y stderr habituales. A continuación se presentan algunas sugerencias sobre cómo implementar el registro. Sin embargo, lo más importante es garantizar que el registro sea coherente, de modo que se pueda acceder a los datos de registro y buscarlos con un mínimo de esfuerzo, ya que para eso se utilizan. El uso de diferentes mecanismos y formatos de registro en diferentes proyectos no es el enfoque correcto.

note: (itstool) path: section/title
en: GLib Logging Framework
es_ES: Entorno de trabajo de registro de GLib

note: (itstool) path: section/title
en: Exceptions
es_ES: Excepciones

note: (itstool) path: item/p
en: Similarly, do not set up log handlers in library code. Log messages should propagate through library code and be handled in a log handler at the top level of an application.
es_ES: Del mismo modo, no configure controladores de registro en el código de la biblioteca. Los mensajes de registro deben propagarse a través del código de la biblioteca y manejarse en un controlador de registro en el nivel superior de una aplicación.

note: (itstool) path: section/title
en: journald Integration
es_ES: Integración con journald

note: (itstool) path: section/title
en: Log Rotation
es_ES: Rotación de registros

note: (itstool) path: page/title
en: GLib Main Contexts
es_ES: Contextos principales de GLib

note: (itstool) path: section/title
en: What is <code>GMainContext</code>?
es_ES: ¿Qué es <code>GMainContext</code>?

note: (itstool) path: item/p
en: Dispatch callbacks from those sources.
es_ES: Enviar retrollamadas de esas fuentes.

note: (itstool) path: section/title
en: What is <code>GMainLoop</code>?
es_ES: ¿Qué es <code>GMainLoop</code>?

note: (itstool) path: section/p
en: It is important not to confuse main contexts with main loops. Main contexts do the bulk of the work: preparing source lists, waiting for events, and dispatching callbacks. A main loop simply iterates a context.
es_ES: Es importante no confundir los contextos principales con los bucles principales. Los contextos principales hacen la mayor parte del trabajo: preparar listas de fuentes, esperar eventos y enviar devoluciones de llamadas. Un bucle principal simplemente itera un contexto.

note: (itstool) path: section/title
en: Default Contexts
es_ES: Contextos predeterminados

note: (itstool) path: section/p
en: Implicit use of the global-default main context means the callback functions are invoked in the main thread, typically resulting in work being brought back from a worker thread into the main thread.
es_ES: El uso implícito del contexto principal global predeterminado significa que las funciones de devolución de llamada se invocan en el hilo principal, lo que generalmente hace que el trabajo sea devuelto desde un hilo de trabajo al hilo principal.

note: (itstool) path: td/p
en: Do not use
es_ES: No use

note: (itstool) path: td/p
en: Use instead
es_ES: Use en su lugar

note: (itstool) path: section/title
en: Using <code>GMainContext</code> in a Library
es_ES: Usar <code>GMainContext</code> en una biblioteca

note: (itstool) path: example/p
en: The example below demonstrates the underlying principles, but there are convenience methods explained below which simplify things.
es_ES: El siguiente ejemplo demuestra los principios subyacentes, pero hay métodos de conveniencia explicados a continuación que simplifican las cosas.

note: (itstool) path: section/title
en: Checking Threading
es_ES: Comprobar los hilos

note: (itstool) path: section/p
en: If that’s put at the top of each function, any assertion failure will highlight a case where a function has been called from the wrong thread. It is much easier to write these assertions when initially developing code, rather than debugging race conditions which can easily result from a function being called in the wrong thread.
es_ES: Si se coloca en la parte superior de cada función, cualquier falla de aserción resaltará un caso en el que se llamó a una función desde el hilo equivocado. Es mucho más fácil escribir estas afirmaciones cuando se desarrolla inicialmente el código, en lugar de depurar las condiciones de carrera que pueden resultar fácilmente de una función que se llama en el hilo incorrecto.

note: (itstool) path: example/p
en: The following can be used:
es_ES: Se puede usar lo siguiente:

note: (itstool) path: info/desc
en: Managing memory allocation and deallocation in C
es_ES: Gestionar la reserva y la liberación de memoria en C

note: (itstool) path: page/title
en: Memory Management
es_ES: Gestión de la memoria

note: (itstool) path: synopsis/p
en: There are three situations to avoid, in order of descending importance:
es_ES: Hay tres situaciones que se deben evitar, en orden descendente de importancia:

note: (itstool) path: item/p
en: Using memory after freeing it (use-after-free).
es_ES: Usar la memoria después de liberar (usar-después-de-liberar).

note: (itstool) path: item/p
en: Using memory before allocating it.
es_ES: Usar memoria antes de reservarla.

note: (itstool) path: section/title
en: Principles of Memory Management
es_ES: Principios de la gestión de la memoria

note: (itstool) path: section/p
en: For example, consider the functions:
es_ES: Por ejemplo, considere las funciones:

note: (itstool) path: td/p
en: Function name
es_ES: Nombre de la función

note: (itstool) path: td/p
en: Convention 1 (standard)
es_ES: Convenio 1 (estándar)

note: (itstool) path: td/p
en: Convention 2 (alternate)
es_ES: Convenio 2 (alternativo)

note: (itstool) path: td/p
en: Convention 3 (<cmd>gdbus-codegen</cmd>)
es_ES: Convenio 3 (<cmd>gdbus-codegen</cmd>)

note: (itstool) path: td/p
en: Unused
es_ES: No usado

note: (itstool) path: section/title
en: Assignments
es_ES: Asignaciones

note: (itstool) path: td/p
en: Copy or move the source to the destination.
es_ES: Copiar o mover la fuente al destino.

note: (itstool) path: td/p
en: Copy the source to the destination.
es_ES: Copiar la fuente en el destino.

note: (itstool) path: td/p
en: Pure assignment.
es_ES: Asignación pura.

note: (itstool) path: section/title
en: Function Calls
es_ES: Llamadas a funciones

note: (itstool) path: section/title
en: Function Returns
es_ES: Retornos de funciones

note: (itstool) path: td/p
en: Pure variable passing.
es_ES: Asignación de variables pura.

note: (itstool) path: section/p
en: Ownership for variables can be documented using inline comments. These are non-standard, and not read by any tools, but can form a convention if used consistently.
es_ES: La propiedad de las variables se puede documentar mediante comentarios en línea. Estos no son estándar y no se leen por ninguna herramienta, pero pueden formar un convenio si se usan de manera consistente.

note: (itstool) path: section/title
en: Floating References
es_ES: Referencias flotantes

note: (itstool) path: example/p
en: Floating references allow the following code to be simplified:
es_ES: Las referencias flotantes permiten simplificar el siguiente código:

note: (itstool) path: section/title
en: Convenience Functions
es_ES: Funciones de conveniencia

note: (itstool) path: section/title
en: Container Types
es_ES: Tipos de contenedores

note: (itstool) path: section/title
en: Verification
es_ES: Verificación

note: (itstool) path: section/title
en: GObject APIs
es_ES: API de GObject

note: (itstool) path: item/p
en: <code>WblSchema</code> structure
es_ES: estructura <code>WblSchema</code>

note: (itstool) path: item/p
en: <code>WblSchemaClass</code> structure
es_ES: estructura <code>WblSchemaClass</code>

note: (itstool) path: item/p
en: <code>WBL_TYPE_SCHEMA</code> macro
es_ES: macro <code>WBL_TYPE_SCHEMA</code>

note: (itstool) path: item/p
en: <code>WBL_IS_SCHEMA</code> macro
es_ES: macro <code>WBL_IS_SCHEMA</code>

note: (itstool) path: item/p
en: <code>wbl_schema_get_type</code> function
es_ES: función <code>wbl_schema_get_type</code>

note: (itstool) path: item/p
en: <code>wbl_schema_new</code> function
es_ES: función <code>wbl_schema_new</code>

note: (itstool) path: item/p
en: <code>wbl_schema_load_from_data</code> function
es_ES: función <code>wbl_schema_load_from_data</code>

note: (itstool) path: section/title
en: Justification
es_ES: Justificación

note: (itstool) path: section/p
en: This is unmaintainable, and asking all the projects to port to a new API at the same time is hard to organize and demoralizing, as most API breaks do not bring large new features which would motivate porting.
es_ES: Esto es imposible de mantener, y pedir que todos los proyectos se transfieran a una nueva API al mismo tiempo es difícil de organizar y desmoralizante, ya que la mayoría de las interrupciones de la API no ofrecen nuevas características grandes que motivaren la transferencia.

note: (itstool) path: section/title
en: Solution
es_ES: Solución

note: (itstool) path: section/p
en: For example, say that library <code>Foo</code> traditionally installs these files:
es_ES: Por ejemplo, la biblioteca <code>Foo</code> instala habitualmente estos archivos:

note: (itstool) path: section/p
en: You might modify <code>Foo</code> version 4 to install these files instead:
es_ES: Puede modificar la versión 4 de <code>Foo</code> para instalar estos archivos en su lugar:

note: (itstool) path: section/p
en: It could then be parallel installed with version 5:
es_ES: Se puede instalar en paralelo con la versión 5:

note: (itstool) path: section/title
en: Version Numbers
es_ES: Números de versión

note: (itstool) path: listing/title
en: API Versioning in Autoconf
es_ES: Versionado de API en Autoconf

note: (itstool) path: section/title
en: C Header Files
es_ES: Archivos de cabecera de C

note: (itstool) path: section/p
en: There’s some temptation to keep one of the header files outside of any subdirectory:
es_ES: Existe la tentación de mantener uno de los archivos de encabezado fuera de cualquier subdirectorio:

note: (itstool) path: listing/title
en: Header Files in Automake
es_ES: Archivos de cabecera en Automake

note: (itstool) path: section/title
en: Libraries
es_ES: Bibliotecas

note: (itstool) path: section/p
en: Library object files should have a versioned name. For example:
es_ES: Los archivos de objetos de la biblioteca deben tener un nombre versionado. Por ejemplo:

note: (itstool) path: section/p
en: This allows applications to get exactly the one they want at compile time, and ensures that versions 4 and 5 have no files in common.
es_ES: Esto permite que las aplicaciones obtengan exactamente lo que desean en el momento de la compilación y garantiza que las versiones 4 y 5 no tengan archivos en común.

note: (itstool) path: section/p
en: Versioned libraries can be built and installed from automake using the following code:
es_ES: Las bibliotecas versionadas se pueden construir e instalar desde automake usando el siguiente código:

note: (itstool) path: listing/title
en: Libraries in Automake
es_ES: Bibliotecas en Automake

note: (itstool) path: section/title
en: pkg-config Files
es_ES: Archivos de pkg-config

note: (itstool) path: listing/title
en: pkg-config Files in Autoconf and Automake
es_ES: Archivos de pkg-config en Autoconf y Automake

note: (itstool) path: section/title
en: Configuration Files
es_ES: Archivos de configuración

note: (itstool) path: section/title
en: Gettext Translations
es_ES: Traducciones de Gettext

note: (itstool) path: section/p
en: Then use <code>GETTEXT_PACKAGE</code> as the package name to pass to <code mime="text/x-csrc">bindtextdomain()</code>, <code mime="text/x-csrc">textdomain()</code>, and <code mime="text/x-csrc">dgettext()</code>.
es_ES: Use <code>GETTEXT_PACKAGE</code> como el nombre del paquete que pasar a <code mime="text/x-csrc">bindtextdomain()</code>, <code mime="text/x-csrc">textdomain()</code>, and <code mime="text/x-csrc">dgettext()</code>.

note: (itstool) path: section/title
en: D-Bus Interfaces
es_ES: Interfaces de D-Bus

note: (itstool) path: list/title
en: Service Names
es_ES: Nombres de servicios

note: (itstool) path: list/title
en: Interface Names
es_ES: Nombres de interfaces

note: (itstool) path: list/title
en: Object Paths
es_ES: Rutas de objetos

note: (itstool) path: section/title
en: Programs, Daemons and Utilities
es_ES: Programas, demonios y utilidades

note: (itstool) path: section/p
en: Given a daemon and utility program:
es_ES: Dado un demonio y un programa de utilidad:

note: (itstool) path: section/p
en: these should be versioned as:
es_ES: se deben versionar como:

note: (itstool) path: page/title (itstool) path: section/title
en: Pre- and Post-Conditions
es_ES: Pre y post-condiciones

note: (itstool) path: item/title
en: Assertions
es_ES: Aserciones

note: (itstool) path: item/p
en: Check for programmer errors and abort the program on failure.
es_ES: Comprobar errores de programación y abortar el programa en caso de error.

note: (itstool) path: item/title
en: Validation
es_ES: Validación

note: (itstool) path: page/title
en: Threading
es_ES: Hilos

note: (itstool) path: item/p
en: Do not use threads if at all possible. (<link xref="#when-to-use-threading"/>)
es_ES: No use hilos siempre que sea posible. (<link xref="#when-to-use-threading"/>)

note: (itstool) path: section/title
en: When to Use Threading
es_ES: Cuándo usar hilos

note: (itstool) path: example/p
en: With an implementation something like:
es_ES: Con una implementación como esta:

note: (itstool) path: section/title
en: Using Threading
es_ES: Usar hilos

note: (itstool) path: section/title
en: Debugging
es_ES: Depurado

note: (itstool) path: page/title
en: Tooling
es_ES: Herramientas

note: (itstool) path: page/p
en: Practically, this means having all compiler and other tool warnings enabled and set to fail the build process with an error if they are emitted.
es_ES: Prácticamente, esto significa tener todas las advertencias del compilador y otras herramientas habilitadas y configuradas para fallar el proceso de compilación con un error si se emiten.

note: (itstool) path: section/title
en: GCC and Clang
es_ES: GCC y Clang

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> to the <file>m4/</file> directory of your project.
es_ES: Copie <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_valgrind_check.m4"> <file>ax_valgrind_check.m4</file></link> en la carpeta <file>m4/</file> de su proyecto.

note: (itstool) path: item/p
en: Add <code>AX_VALGRIND_CHECK</code> to <file>configure.ac</file>.
es_ES: Añada <code>AX_VALGRIND_CHECK</code> a <file>configure.ac</file>.

note: (itstool) path: item/p
en: Add <code>@VALGRIND_CHECK_RULES@</code> to the <file>Makefile.am</file> in each directory which contains unit tests.
es_ES: Añada <code>@VALGRIND_CHECK_RULES</code> al archivo <file>Makefile.am</file> en cada carpeta que contenga pruebas unitarias.

note: (itstool) path: section/p
en: When <cmd>make check-valgrind</cmd> is run, it will save its results in <file>test-suite-*.log</file>, one log file per tool. Note that you will need to run it from the directory containing the unit tests.
es_ES: Cuando se ejecuta <cmd>make check-valgrind</cmd> guarda los resultados en <file>test-suite-*.log</file>, un archivo de registro por herramienta. Tenga en cuenta que necesitará ejecutarlo en la carpeta que contiene las pruebas unitarias.

note: (itstool) path: section/p
en: To run memcheck manually on an installed program, use:
es_ES: Para ejecutar memcheck manualmente en un programa instalado, use:

note: (itstool) path: section/p
en: <cmd>valgrind --tool=memcheck --leak-check=full <var>my-program-name</var></cmd>
es_ES: <cmd>valgrind --tool=memcheck --leak-check=full <var>nombre-del-programa</var></cmd>

note: (itstool) path: section/p
en: <cmd>libtool exec valgrind --tool=memcheck --leak-check=full <var>./my-program-name</var></cmd>
es_ES: <cmd>libtool exec valgrind --tool=memcheck --leak-check=full <var>./nombre-del-programa</var></cmd>

note: (itstool) path: section/title
en: cachegrind and KCacheGrind
es_ES: cachegrind y KCacheGrind

note: (itstool) path: section/title
en: helgrind and drd
es_ES: helgrind y drd

note: (itstool) path: section/p
en: To add <code>AX_CODE_COVERAGE</code> support to a project:
es_ES: Para añadir soporte de <code>AX_CODE_COVERAGE</code> a un proyecto:

note: (itstool) path: item/p
en: Copy <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> to the <file>m4/</file> directory of your project.
es_ES: Copie <link href="http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_code_coverage.m4"> <file>ax_code_coverage.m4</file></link> al a carpeta <file>m4/</file> de su proyecto.

note: (itstool) path: item/p
en: Add <code>AX_CODE_COVERAGE</code> to <file>configure.ac</file>.
es_ES: Añada <code>AX_CODE_COVERAGE</code> a <file>configure.ac</file>.

note: (itstool) path: item/p
en: Add <code>@CODE_COVERAGE_RULES</code> to the top-level <file>Makefile.am</file>.
es_ES: Añada <code>@CODE_COVERAGE_RULES</code> al nivel superior de <file>Makefile.am</file>.

note: (itstool) path: section/p
en: Coverity is good, but it is not perfect, and it does produce a number of false positives. These should be marked as ignored in the online interface.
es_ES: La cobertura es buena, pero no perfecta y ciertamente produce una serie de falsos positivos. Estos deben marcarse como ignorados en la interfaz en línea.

note: (itstool) path: section/title
en: Clang Static Analyzer
es_ES: Analizador estático Clang

note: (itstool) path: section/p
en: A full tutorial on using Clang is <link href="http://clang-analyzer.llvm.org/scan-build.html">here</link>.
es_ES: <link href="http://clang-analyzer.llvm.org/scan-build.html">Aquí</link> tiene un tutorial completo del uso de Clang.

note: (itstool) path: section/p
en: Tartan is still young software, and will produce false positives and may crash when run on some code. However, it can find legitimate bugs quite quickly, and is worth running over a code base frequently to detect new errors in the use of GLib in the code. Please <link href="http://people.collabora.com/~pwith/tartan/#troubleshooting"> report any problems with Tartan</link>.
es_ES: Tartan es todavía un software joven, y producirá falsos positivos y puede fallar cuando se ejecuta en algún código. Sin embargo, puede encontrar errores legítimos con bastante rapidez y vale la pena ejecutarlo sobre un código base con frecuencia para detectar nuevos errores en el uso de GLib en el código. Por favor<link href="http://people.collabora.com/~pwith/tartan/#troubleshooting"> informe de cualquier problema con Tartan</link>.

note: (itstool) path: section/p
en: A full tutorial on enabling Tartan for use with the Clang static analyzer is <link href="http://people.collabora.com/~pwith/tartan/#usage-standalone"> here</link>. If set up correctly, the output from Tartan will be mixed together with the normal static analyzer output.
es_ES: <link href="http://people.collabora.com/~pwith/tartan/#usage-standalone">Aquí</link> tiene un tutorial completo sobre la habilitación de Tartan para usarlo con el analizador estático de Clang. Si se configura correctamente, la salida del Tartan se mezclará junto con la salida normal del analizador estático.

note: (itstool) path: info/desc
en: Designing software to be tested and writing unit tests for it
es_ES: Diseñar software para ser probado y escribir pruebas unitarias para él

note: (itstool) path: page/title
en: Unit Testing
es_ES: Pruebas unitarias

note: (itstool) path: synopsis/p
en: Unit testing should be the primary method of testing the bulk of code written, because a unit test can be written once and run many times — manual tests have to be planned once and then manually run each time.
es_ES: Las pruebas unitarias deben ser el método principal para probar la mayor parte del código escrito, porque una prueba unitaria puede escribirse una vez y ejecutarse muchas veces; las pruebas manuales deben planificarse una vez y luego ejecutarse manualmente cada vez.

note: (itstool) path: synopsis/p
en: Development of unit tests starts with the architecture and API design of the code to be tested: code should be designed to be easily testable, or will potentially be very difficult to test.
es_ES: El desarrollo de las pruebas unitarias comienza con la arquitectura y el diseño de la API del código que se va a probar: el código debe diseñarse para que se pueda probar fácilmente, o será potencialmente muy difícil de probar.

note: (itstool) path: item/p
en: Write unit tests to be as small as possible, but no smaller. (<link xref="#writing-unit-tests"/>)
es_ES: Escriba pruebas unitarias para que sean lo más pequeñas posible, pero no más pequeñas. (<link xref="#writing-unit-tests"/>)

note: (itstool) path: item/p
en: Use code coverage tools to write tests to get high code coverage. (<link xref="#writing-unit-tests"/>)
es_ES: Utilice herramientas de cobertura de código para escribir pruebas para obtener una cobertura de código alta. (<link xref="#writing-unit-tests"/>)

note: (itstool) path: item/p
en: Run all unit tests under Valgrind to check for leaks and other problems. (<link xref="#leak-checking"/>)
es_ES: Ejecute todas las pruebas unitarias en Valgrind para comprobar si hay fugas y otros problemas. (<link xref="#leak-checking"/>)

note: (itstool) path: item/p
en: Use appropriate tools to automatically generate unit tests where possible. (<link xref="#test-generation"/>)
es_ES: Utilice herramientas apropiadas para generar pruebas unitarias automáticamente donde sea posible. (<link xref="#test-generation"/>)

note: (itstool) path: item/p
en: Design code to be testable from the beginning. (<link xref="#writing-testable-code"/>)
es_ES: Diseñe el código para ser comprobable desde el principio. (<link xref="#writing-testable-code"/>)

note: (itstool) path: section/title
en: Writing Unit Tests
es_ES: Escribir pruebas unitarias

note: (itstool) path: section/p
en: Unit tests should be written in conjunction with looking at <link xref="tooling#gcov-and-lcov">code coverage information gained from running the tests</link>. This typically means writing an initial set of unit tests, running them to get coverage data, then reworking and expanding them to increase the code coverage levels. Coverage should be increased first by ensuring all functions are covered (at least in part), and then by ensuring all lines of code are covered. By covering functions first, API problems which will prevent effective testing can be found quickly. These typically manifest as internal functions which cannot easily be called from unit tests. Overall, coverage levels of over 90% should be aimed for; don’t just test cases covered by project requirements, test everything.
es_ES: Las pruebas unitarias deben escribirse junto con la observación de la  <link xref="tooling#gcov-and-lcov">información de cobertura obtenida de la ejecución de las pruebas</link>. Por lo general, esto significa escribir un conjunto inicial de pruebas unitarias, ejecutarlas para obtener datos de cobertura, luego volver a trabajar y expandirlas para aumentar los niveles de cobertura del código. La cobertura debe aumentarse primero asegurándose de que todas las funciones están cubiertas (al menos en parte) y luego asegurándose de que todas las líneas de código están cubiertas. Al cubrir las funciones primero, los problemas de la API que evitarán la realización de pruebas efectivas se pueden encontrar rápidamente. Normalmente, se manifiestan como funciones internas a las que no se puede llamar fácilmente desde las pruebas unitarias. Habitualmente, se debe apuntar a niveles de cobertura superiores al 90%; no pruebe sólo los casos cubiertos por los requisitos del proyecto, pruebe todo.

note: (itstool) path: section/p
en: Like <link xref="version-control">git commits</link>, each unit test should be ‘as small as possible, but no smaller’, testing a single specific API or behavior. Each test case must be able to be run individually, without depending on state from other test cases. This is important to allow debugging of a single failing test, without having to step through all the other test code as well. It also means that a single test failure can easily be traced back to a specific API, rather than a generic ‘unit tests failed somewhere’ message.
es_ES: Al igual que con <link xref="version-control">git commits</link>,  cada prueba unitaria debería ser “tan pequeña como sea posible, pero no más pequeña”, probando una sola API o comportamiento. Cada caso de prueba debe ser capaz de ejecutarse individualmente, sin depender del estado de otros casos de prueba. Esto es importante para permitir la depuración de una prueba errónea sin tener que recorrer también todos los demás códigos de prueba. También significa que una única prueba errónea se puede rastrear fácilmente a una API específica, en lugar de un mensaje genérico de “las pruebas unitarias fallaron en algún lugar”.

note: (itstool) path: section/p
en: GLib has support for unit testing with its <link href="https://developer.gnome.org/glib/stable/glib-Testing.html">GTest framework</link>, allowing tests to be arranged in groups and hierarchies. This means that groups of related tests can be run together for enhanced debugging too, by running the test binary with the <cmd>-p</cmd> argument: <cmd>./test-suite-name -p /path/to/test/group</cmd>.
es_ES: GLib tiene soporte para pruebas unitarias con su <link href="https://developer.gnome.org/glib/stable/glib-Testing.html">GTest framework</link>, que permite organizar las pruebas en grupos y jerarquías. Esto significa que los grupos de pruebas relacionadas también se pueden ejecutar juntos para una mejor depuración, ejecutando el binario de prueba con el argumento <cmd>-p</cmd> : <cmd>./test-suite-name -p /path/to/test/group</cmd>.

note: (itstool) path: section/title
en: Installed Tests
es_ES: Pruebas instaladas

note: (itstool) path: section/p
en: All unit tests should be installed system-wide, following the <link href="https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests">installed-tests standard</link>.
es_ES: Todas las pruebas unitarias deberían instalarse en todo el sistema, siguiendo el <link href="https://wiki.gnome.org/Initiatives/GnomeGoals/InstalledTests">estándar de pruebas instaladas</link>.

note: (itstool) path: section/p
en: By installing the unit tests, continuous integration (CI) is made easier, since tests for one project can be re-run after changes to other projects in the CI environment, thus testing the interfaces between modules. That is useful for a highly-coupled set of projects like GNOME.
es_ES: Mediante la instalación de pruebas unitarias, la integración continua (IC) se hace más fácil, ya que las pruebas para un proyecto se pueden volver a ejecutar después de cambios en otros proyectos en el entorno IC, probando así las interfaces entre módulos. Esto es útil para un conjunto de proyecto altamente acoplados como GNOME.

note: (itstool) path: section/p
en: To add support for installed-tests, add the following to <file>configure.ac</file>:
es_ES: Para añadir compatibilidad con las pruebas instaladas, añada lo siguiente a <file>configure.ac</file>:

note: (itstool) path: section/p
en: Then in <file>tests/Makefile.am</file>:
es_ES: En el <file>tests/Makefile.am</file>:

note: (itstool) path: section/title
en: Leak Checking
es_ES: Comprobación de fugas

note: (itstool) path: section/p
en: Once unit tests with high code coverage have been written, they can be run under various dynamic analysis tools, such as <link xref="tooling#valgrind">Valgrind</link> to check for leaks, threading errors, allocation problems, etc. across the entire code base. The higher the code coverage of the unit tests, the more confidence the Valgrind results can be treated with. See <link xref="tooling"/> for more information, including build system integration instructions.
es_ES: Una vez se han escrito pruebas unitarias con alta cobertura de código, se pueden ejecutar bajo varias herramientas de análisis dinámico, como <link xref="tooling#valgrind">Valgrind</link> para comprobar si hay fugas, errores de ejecución de hilos, problemas de asignación, etc. en toda la base del código. Cuanto mayor sea la cobertura del código de las pruebas unitarias, más fiables serás los resultados de Valgrind. Véase <link xref="tooling"/> para más información, incluyendo las instrucciones de integración de sistemas de compilación.

note: (itstool) path: section/p
en: Critically, this means that unit tests should not leak memory or other resources themselves, and similarly should not have any threading problems. Any such problems would effectively be false positives in the analysis of the actual project code. (False positives which need to be fixed by fixing the unit tests.)
es_ES: Críticamente, esto significa que las pruebas unitarias no deberían perder memoria u otros recursos, y de manera similar no deberían tener problemas de ejecución de hilos. Todos estos problemas serían efectivamente falsos positivos en el análisis del código real del proyecto. (Los falsos positivos que deben corregirse arreglando las pruebas unitarias).

note: (itstool) path: section/title
en: Test Generation
es_ES: Generación de pruebas

note: (itstool) path: section/p
en: Certain types of code are quite repetitive, and require a lot of unit tests to gain good coverage; but are appropriate for <link href="https://en.wikipedia.org/wiki/Test_data_generation">test data generation</link>, where a tool is used to automatically generate test vectors for the code. This can drastically reduce the time needed for writing unit tests, for code in these specific domains.
es_ES: Ciertos tipos de código son bastante repetitivos y requieren muchas pruebas unitarias para obtener una buena cobertura; pero son apropiados para la <link href="https://en.wikipedia.org/wiki/Test_data_generation">generación de datos de prueba</link>, donde se utiliza una herramienta para generar automáticamente vectores de prueba para el código. Esto puede reducir drásticamente el tiempo necesario para escribir pruebas unitarias para el código en esto dominios específicos.

note: (itstool) path: section/p
en: One example of a domain amenable to test data generation is parsing, where the data to be parsed is required to follow a strict schema — this is the case for XML and JSON documents. For JSON, a tool such as <link href="http://people.collabora.com/~pwith/walbottle/">Walbottle</link> can be used to generate test vectors for all types of valid and invalid input according to the schema.
es_ES: Un ejemplo de dominio dispuesto para probar la generación de datos es el análisis, donde los datos que se van a analizar deben seguir un esquema estricto — este es el caso de los documentos XML y JSON. Para JSON una herramienta como <link href="http://people.collabora.com/~pwith/walbottle/">Walbottle</link> se puede utilizar para generar vectores de prueba para todo tipo de entradas válidas y no válidas de acuerdo con el esquema.

note: (itstool) path: section/p
en: Every type of JSON document should have a <link href="http://json-schema.org/">JSON Schema</link> defined for it, which can then be passed to Walbottle to generate test vectors:
es_ES: Cada tipo de documento JSON debe tener un <link href="http://json-schema.org/">esquema JSON</link> definido para él, que luego puede  pasarse a Walbottle para generar vectores de prueba:

note: (itstool) path: section/p
en: These test vectors can then be passed to the code under test in its unit tests. The JSON instances generated by <cmd>--valid-only</cmd> should be accepted; those from <cmd>--invalid-only</cmd> should be rejected.
es_ES: Estos vectores de prueba pueden usarse al código que se está probando en sus pruebas unitarias. Las instancias JSON generadas por <cmd>—valid-only</cmd> se deben aceptar; las de <cmd>—invalid-only</cmd> se deben rechazar.

note: (itstool) path: section/title
en: Writing Testable Code
es_ES: Escribir código comprobable

note: (itstool) path: section/p
en: Code should be written with testability in mind from the design stage, as it affects API design and architecture in fundamental ways. A few key principles:
es_ES: El código se debe escribir con la capacidad de prueba en mente desde la fase de diseño, ya que afecta al diseño y a la arquitectura de la API de manera fundamental. Algunos principios clave:

note: (itstool) path: item/p
en: Do not use global state. Singleton objects are usually a bad idea as they can’t be instantiated separately or controlled in the unit tests.
es_ES: No utilice el estado global. Los objetos Singleton generalmente son una mala idea, ya que no pueden instanciarse por separado ni controlarse en las pruebas unitarias.

note: (itstool) path: item/p
en: Separate out use of external state, such as databases, networking, or the file system. The unit tests can then replace the accesses to external state with mocked objects. A common approach to this is to use dependency injection to pass a file system wrapper object to the code under test. For example, a class should not load a global database (from a fixed location in the file system) because the unit tests would then potentially overwrite the running system’s copy of the database, and could never be executed in parallel. They should be passed an object which provides an interface to the database: in a production system, this would be a thin wrapper around the database API; for testing, it would be a mock object which checks the requests given to it and returns hard-coded responses for various tests.
es_ES: Separe el uso del estado externo, como bases de datos, redes o el sistema de archivos. Las pruebas unitarias pueden reemplazar los accesos al estado externo con objetos simulados. Un enfoque común a esto es usar la inyección de dependencias para pasar un objeto contenedor del sistema de archivos al código que se está probando. Por ejemplo, una clase no debería cargar una base de datos global (desde una ubicación fija en el sistema de archivos) porque las pruebas unitarias podrían sobrescribir la copia de la base de datos del sistema en ejecución y nunca podrían ejecutarse en paralelo. Se les debe pasar un objeto que proporcione una interfaz a la base de datos: en un sistema en producción, esto sería una envoltura delgada alrededor de la API de la base de datos; para las pruebas, sería un objeto simulado que verifica las solicitudes que recibe y devuelve respuestas codificadas para varias pruebas.

note: (itstool) path: item/p
en: Expose utility functions where they might be generally useful.
es_ES: Exponga las funciones de utilidad donde puedan ser generalmente útiles.

note: (itstool) path: item/p
en: Split projects up into collections of small, private libraries which are then linked together with a minimal amount of glue code into the overall executable. Each can be tested separately.
es_ES: Divida los proyectos en colecciones de pequeñas bibliotecas privadas que luego se unen con una cantidad mínima de código de pegamento en el ejecutable general. Cada una se puede probar por separado.

note: (itstool) path: section/p
en: The topic of software testability is covered in the following articles:
es_ES: El tema de la comprobabilidad se cubre en los siguientes artículos:

note: (itstool) path: item/p
en: <link href="http://msdn.microsoft.com/en-us/magazine/dd263069.aspx">Design for testability</link>
es_ES: <link href="http://msdn.microsoft.com/en-us/magazine/dd263069.aspx">Diseño para la comprobabilidad</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Software_testability">Software testability</link>
es_ES: <link href="https://en.wikipedia.org/wiki/Software_testability">Verificación de software</link>

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Dependency_injection">Dependency injection</link>
es_ES: <link href="https://en.wikipedia.org/wiki/Dependency_injection">Inyección de dependencias</link>

note: (itstool) path: item/p
en: <link href="http://c2.com/cgi/wiki?SoftwareDesignForTesting">Software design for testing</link>
es_ES: <link href="http://c2.com/cgi/wiki?SoftwareDesignForTesting">Diseño de software para pruebas</link>

note: (itstool) path: info/desc
en: Source code version control with git
es_ES: Control de versiones de código con git

note: (itstool) path: page/title
en: Version Control
es_ES: Control de versiones

note: (itstool) path: synopsis/p
en: git is used for version control for all GNOME projects. This page assumes good working knowledge of git; some introductory material is available <link href="https://www.atlassian.com/git/tutorials/">here</link>, and a <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">git cheatsheet is here</link>.
es_ES: git se utiliza como control de versiones para todos los proyecto de GNOME. Esta página asume un buen conocimiento de trabajo con git; algunos materiales introductorios están disponibles<link href="https://www.atlassian.com/git/tutorials/">aquí</link>, y <link href="https://training.github.com/kit/downloads/github-git-cheat-sheet.pdf">aquí hay una chuleta de git</link>.

note: (itstool) path: item/p
en: Make atomic, revertable commits. (<link xref="#guidelines-for-making-commits"/>)
es_ES: Haga commits atómicos y reversibles. (<link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Include full reasoning in commit messages, plus links to relevant bug reports or specifications. (<link xref="#guidelines-for-making-commits"/>)
es_ES: Incluya un razonamiento completo en los mensajes de commit, así como enlaces a los informes de error o a la especificaciones. (Consulte la sección <link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Keep large changes, such as renames, in separate commits. (<link xref="#guidelines-for-making-commits"/>)
es_ES: Haga los cambios grandes, como los renombrados, en commits separados. (Consulte la sección <link xref="#guidelines-for-making-commits"/>)

note: (itstool) path: item/p
en: Merge changes from feature branches by rebasing. (<link xref="#use-of-git"/>)
es_ES: Fusione los cambios de las ramas de características haciendo rebase.  (<link xref="#use-of-git"/>)

note: (itstool) path: section/title
en: Use of Git
es_ES: Uso de Git

note: (itstool) path: section/p
en: Most GNOME repositories follow these rules:
es_ES: La mayoría de los repositorios de GNOME siguen estas reglas:

note: (itstool) path: item/p
en: No forced pushes. Except for branches with the <code>wip/</code> prefix (work-in-progress), the commits’ history must not be modified, as contributors rely on it.
es_ES: No fuerce los envíos. Excepto para las rama con el prefijo <code>wip</code> (work-in-progress), el historial de commit no debe modificarse, ya que los colaboradores confían en él.

note: (itstool) path: item/p
en: Rebase commits rather than merging, to have a linear history (which is easier to follow).
es_ES: Rebase los commits en lugar de mezclarlos, para tener un histórico lineal (más fácil de seguir).

note: (itstool) path: item/p
en: Work on feature branches on GNOME git in <code>wip/</code> branches, then rebase on master and fast-forward merge the changes. It is a good practice to also add your nickname to the branch name, as <code>wip/nickname/feature</code>.
es_ES: Trabaje en ramas de características en GNOME git en ramas <code>git</code>, después haga rebase en master y fusione rápidamente los cambios. Es una buena práctica añadir también su apodo al nombre de la rama, como <code>wip/apodo/feature</code>.

note: (itstool) path: item/p
en: Hide <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">sausage making</link> by squashing commits before merging.
es_ES: Ocultar <link href="https://sethrobertson.github.io/GitBestPractices/#sausage">elaboración de salchichas</link> juntando los commits antes de fusionarlos.

note: (itstool) path: section/title
en: Guidelines for Making Commits
es_ES: Guía para realizar commits

note: (itstool) path: section/p
en: Commits should be as small as possible, but no smaller. Each commit should address a single issue, containing only changes related to that issue. The message for each commit should describe the issue, explain what causes it, and explain how it has been fixed if it is not obvious. If the commit is associated with a bug report, the full URI for the bug report should be put on a line by itself at the bottom of the commit message. Similarly, the ID for the git commit (from <cmd>git log --oneline</cmd>) should be copied into the bug report once the commit has been pushed, so it is easy to find one from the other.
es_ES: Los commits deben ser tan pequeños como sea posible, pero no más pequeños. Cada commit debe abordar un único problema, conteniendo solo cambios relacionados con ese problema. El mensaje para cada commit debe describir el problema, explicar qué lo causa y explicar cómo se ha corregido si no es obvio. Si el commit está asociado con un informe de error  la URI completa del informe de error debe ponerse en una línea separada en la parte inferior del mensaje del commit. De la misma forma, el ID para el git commit (de <cmd>git log —oneline</cmd>) debe copiarse en el informe de error una vez se haya enviado el commit, para que sea fácil encontrar uno desde el otro.

note: (itstool) path: section/p
en: The changes in each commit should be easy to read. For example, they should not unnecessarily change whitespace or indentation. Large, mechanical changes, such as renaming a file or function, should be put in separate commits from modifications to code inside that file or function, so that the latter changes do not get buried and lost in the former.
es_ES: Los cambios en cada commit deben ser fáciles de leer. Por ejemplo, no deben cambiar innecesariamente el espacio en blanco o la sangría. Los cambios mecánicos grandes, como el renombrado de un archivo o una función, deben ponerse en commits separados de las modificaciones en el código dentro de ese archivo o función, para que los últimos cambios no queden enterrados y se pierdan en el primero.

note: (itstool) path: section/p
en: The following principles give the reasoning for all the advice above:
es_ES: Los siguientes principios dan el razonamiento para todos los consejos anteriores:

note: (itstool) path: item/p
en: Each commit should take the repository from one working state to another, otherwise <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">bisection</link> is impossible.
es_ES: Cada commit debe llevar el repositorio de un estado de trabajo a otro, de lo contrario la <link href="http://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#Binary-Search">búsqueda binaria</link> es imposible.

note: (itstool) path: item/p
en: Each commit should be individually revertable. If it later turns out that the commit was a bad idea, <cmd>git revert <var>commit ID</var></cmd> should take the repository from a working state to another working state.
es_ES: Cada commit debe ser reversible individualmente. Si después resulta que el commit fue una mala idea, <cmd>git revert <var>commit ID</var></cmd> debe llevar el repositorio de un estado de trabajo a otro estado de trabajo.

note: (itstool) path: item/p
en: The reasoning for each commit, and its relationship to external resources like specifications and bug reports, should be clear, to the extent that commits written by one developer a year in the past should still be understandable by a second developer without having to trace through the changes and work out what they do.
es_ES: El razonamiento de cada commit y su relación con recursos externos, como especificaciones e informe de errores, deben ser claros, de manera que esos commits escritos por un desarrollador un año atrás aún deben ser comprensibles por un segundo desarrollador sin tener que rastrear los cambios y averiguar lo que hacen.

note: (itstool) path: item/p
en: Each commit should be written once, and designed to be read many times, by many reviewers and future programmers.
es_ES: Cada commit debe escribirse una vez y diseñarse para ser leído muchas veces por muchos revisores y futuros programadores.

note: (itstool) path: section/title
en: Merging Procedure
es_ES: Procedimiento de fusión

note: (itstool) path: section/p
en: To merge a feature branch named <code>my-branch</code> into master, use the following commands:
es_ES: Para fusionar una rama de característica llamada <code>my-branch</code> en master, utilice los siguientes comandos:

note: (itstool) path: item/p
en: <link href="https://sethrobertson.github.io/GitBestPractices/">Git best practices</link>
es_ES: <link href="https://sethrobertson.github.io/GitBestPractices/">Buenas prácticas de Git</link>

note: (itstool) path: item/p
en: <link href="https://help.github.com/categories/using-git/">Git FAQ</link>
es_ES: <link href="https://help.github.com/categories/using-git/">P+F de Git</link>

note: (itstool) path: item/p
en: <link href="https://www.atlassian.com/git/tutorials/">Atlassian git tutorial</link>
es_ES: <link href="https://www.atlassian.com/git/tutorials/">Tutorial de Atlassian sobre git</link>

note: (itstool) path: item/p
en: <link href="http://git-scm.com/docs/gittutorial">Official git tutorial</link>
es_ES: <link href="http://git-scm.com/docs/gittutorial">Tutorial oficial de git</link>

note: (itstool) path: item/p
en: <link href="https://try.github.io/">Interactive git tutorial</link>
es_ES: <link href="https://try.github.io/">Tutorial interactivo de  git</link>

note: (itstool) path: item/p
en: <link href="http://www.git-tower.com/learn/">git-tower tutorial</link>
es_ES: <link href="http://www.git-tower.com/learn/">Tutorial de git-tower</link>

note: (itstool) path: info/desc
en: Versioning and releasing libraries and applications
es_ES: Versionado y publicación de bibliotecas y aplicaciones

note: (itstool) path: synopsis/p
en: Module versioning differs for libraries and applications: libraries need a libtool version specified in addition to their package version. Applications just have a package version.
es_ES: La versión del módulo difiere para bibliotecas y aplicaciones: las bibliotecas necesitan una versión de libtool especificada además de su versión de paquete. Las aplicaciones solo tienen una versión de paquete.

note: (itstool) path: item/p
en: Libraries and applications have a package version of the form <em>major.minor.micro</em>. (<link xref="#package-versioning"/>)
es_ES: Las bibliotecas y aplicaciones tienen una versión de paquete de la forma <em>major.minor.micro</em>. (<link xref="#package-versioning"/>)

note: (itstool) path: item/p
en: Libraries additionally have a libtool version of the form <em>current:revision:age</em>. (<link xref="#libtool-versioning"/>)
es_ES: Las bibliotecas además tienen una versión de libtool de la forma <em>current:revision:age</em>. (<link xref="#libtool-versioning"/>)

note: (itstool) path: item/p
en: Version numbers should be updated for each release (using release and post-release increments). (<link xref="#release-process"/>)
es_ES: Los números de versión deben actualizarse para cada versión (usando incrementos de versión y post-versión). (<link xref="#release-process"/>)

note: (itstool) path: item/p
en: Package versions should be incremented for feature changes or additions. (<link xref="#package-versioning"/>)
es_ES: Las versiones de paquete se deben incrementar  para cambios de características o adiciones. (<link xref="#package-versioning"/>)

note: (itstool) path: item/p
en: Libtool versions should be updated for API changes or additions. (<link xref="#libtool-versioning"/>)
es_ES: Las versiones de Libtool deben actualizarse para cambios o adiciones de API. (<link xref="#libtool-versioning"/>)

note: (itstool) path: item/p
en: Even/odd <em>minor</em> package versions can be used respectively for stable/unstable releases. (<link xref="#stable-unstable-versions"/>)
es_ES: Las versiones <em>menores</em> pares/impares de paquetes se pueden usar respectivamente para versiones estables/inestables. (<link xref="#stable-unstable-versions"/>)

note: (itstool) path: section/title
en: Package Versioning
es_ES: Versionado de paquetes

note: (itstool) path: section/p
en: Both libraries and applications have a package version of the form <em>major.minor.micro</em>.
es_ES: Tanto las bibliotecas como las aplicaciones tienen una versión de paquete de la forma <em>major.minor.micro</em>.

note: (itstool) path: section/p
en: The package version number is that passed to <code>AC_INIT()</code>, and the one which is typically known as the project’s version number. For example, the Debian package for a library will use the library’s package version (though may also include the major version number in the package name to allow for <link xref="parallel-installability">parallel installability</link>). Package versions are updated by the following rules:
es_ES: El número de versión del paquete es el que se pasa a <code>AC_INIT()</code>, y el que se suele conocer como número de versión del proyecto. Por ejemplo, el paquete Debian para una biblioteca  utilizará la versión del paquete de la biblioteca (aunque también puede incluir el numero de versión principal en el nombre del paquete para permitir <link xref="parallel-installability">instabilidad en paralelo</link>). Las versiones del paquete son actualizadas con las siguientes reglas:

note: (itstool) path: item/p
en: If breaking <link xref="api-stability">API compatibility</link> in a library, or making a large change to an application which affects everything (such as a UI redesign), increment major and set minor and micro to 0.
es_ES: Si en una biblioteca se rompe <link xref="api-stability">la compatibilidad API</link>, o se hace un gran cambio a una aplicación que afecta a todo (como un rediseño de IU), incremente la  versión principal, y establezca la menor y la micro a 0.

note: (itstool) path: item/p
en: Otherwise, if changing or adding a feature, or adding any API, increment minor and set micro to 0.
es_ES: De lo contrario, si cambia o agrega una característica, o agrega cualquier API, incremente la menor y establezca la micro en 0.

note: (itstool) path: item/p
en: Otherwise (if making a release containing only bug fixes and translation updates), increment micro.
es_ES: En caso contrario (si se hace una publicación que contenga sólo correcciones de errores y actualizaciones de traducciones), se incrementa la microversión.

note: (itstool) path: section/p
en: Note that the minor version number should be updated if any API is added.
es_ES: Tenga en cuenta que el número de versión menor debería actualizarse si se añade alguna API.

note: (itstool) path: section/title
en: Libtool Versioning
es_ES: Versionado de Libtool

note: (itstool) path: section/p
en: Libraries have two version numbers: a libtool version which tracks ABI backwards compatibility (see <link xref="api-stability"/>), and a package version which tracks feature changes. These are normally incremented in synchronization, but should be kept separate because ABI backwards compatibility is not necessarily related to feature changes or bug fixes. Furthermore, the two version numbers have different semantics, and cannot be automatically generated from each other.
es_ES: Las bibliotecas tienen dos números de versión: una versión libtool que rastrea la compatibilidad ABI posterior (<link href="api-stability"/>). y una versión de paquete que rastrea los cambios de las características. Estos normalmente se incrementan sincronizadamente, pero deberían mantenerse separados porque la compatibilidad ABI posterior no está necesariamente relacionada con los cambios de las características o las correcciones de errores. Además, los dos números de versión tienen distintos significados, y no puede generarse automáticamente el uno desde el otro.

note: (itstool) path: section/p
en: A good overview of libtool versioning, and the differences from package versioning, is given in the <link href="https://autotools.io/libtool/version.html">Autotools Mythbuster</link>; another is in the <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">libtool manual</link>.
es_ES: Un buen resumen del versionado libtool, y las diferencias con el versionado del paquete, se da en el <link href="https://autotools.io/libtool/version.html">cazador de mitos de Autotools</link>; otro está en el <link href="http://www.gnu.org/s/libtool/manual/html_node/Updating-version-info.html">manual de libtool</link>.

note: (itstool) path: section/p
en: To update the libtool version, follow the algorithm given in the comments below. This is a typical <file>configure.ac</file> snippet for setting up libtool versioning:
es_ES: Para actualizar la versión libtool, siga el algoritmo dado en los comentarios debajo. Este es un fragmento de código <file>configure.ac</file> típico para configurar el versionado libtool:

note: (itstool) path: section/p
en: The following snippet can be used in a <file>Makefile.am</file> to pass that version info to libtool:
es_ES: El siguiente fragmento de código se puede usar en un <file>Makefile.am</file> para pasar esa información de versión a libtool:

note: (itstool) path: section/title
en: Stable and Unstable Package Versions
es_ES: Versiones de paquetes estables e inestables

note: (itstool) path: section/p
en: Most GNOME modules follow a convention for stable and unstable releases. The minor version is even for stable releases and is odd for unstable releases. For example, the 3.20.* versions are stable, but the 3.19.* versions are unstable. The 3.19.* versions can be seen as alpha and beta releases of the 3.20 version.
es_ES: La mayoría de los módulos de GNOME siguen una convención para publicaciones estables e inestables. La versión menor es par para liberaciones estables y es impar para las inestables. Por ejemplo, las versiones 3.20.* son estables, pero las versiones 3.19.* son inestables. Las versiones 3.19.* se pueden ver como entregas alfa y beta de la versión 3.20.

note: (itstool) path: section/p
en: A new micro <em>stable</em> version (e.g. 3.20.0 → 3.20.1) doesn’t add new features, only translation updates and bug fixes. On the other hand, <em>unstable</em> micro releases (e.g. 3.19.1 → 3.19.2) can add API, or change or remove API which was added in a previous micro release in that minor series.
es_ES: Una nueva microversión <em>estable</em> (por ejemplo 3.20.0 → 3.20.1) no añade nuevas características, sólo actualizaciones de traducciones y corrección de errores. Por otro lado, las micropublicaciones <em>inestables</em> (por ejemplo 3.19.1 → 3.19.2) pueden añadir API, o cambiar o eliminar la API que se añadió en la micropublicación anterior en esa serie menor.

note: (itstool) path: section/p
en: The libtool version should be updated only for stable package versions.
es_ES: La versión libtool debería actualizarse sólo para versiones de paquete estables.

note: (itstool) path: section/title
en: Release Process
es_ES: Proceso de publicación

note: (itstool) path: section/p
en: The standard process for making a release of a module increments the libtool version (if the module is a library) at the time of release, then increments the package version number immediately afterwards (this is called a post-release increment).
es_ES: El proceso estándar para hacer una publicación de un módulo incrementa la versión libtool (si el módulo es una biblioteca) en el momento de la entrega, por lo que incrementa el número de versión del paquete inmediatamente después (a esto se le llama un incremento posterior a la publicación).

note: (itstool) path: section/p
en: Updating the libtool versions at the time of release means that they are only incremented once for all ABI changes in a release. The use of post-release increment for package versions means the package version number is not outdated (still equal to the previous release) during the development cycle.
es_ES: La actualización de las versiones libtool durante el tiempo de publicación significa que sólo se incrementan una vez para todos los cambios ABI de una entrega. Usar el incremento posterior a la publicación para las versiones del paquete significa que el número de versión del paquete no está desactualizado (aún igual al de la entrega anterior) durante el ciclo de desarrollo.

note: (itstool) path: section/p
en: The release process (based on the <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">GNOME release process</link>):
es_ES: El proceso de la publicación (basado en el <link href="https://wiki.gnome.org/MaintainersCorner/Releasing">proceso de publicación de GNOME</link>):

note: (itstool) path: item/p
en: Make sure code is up to date: <cmd>git pull</cmd>
es_ES: Asegúrese de que el código está actualizado: <cmd>git pull</cmd>

note: (itstool) path: item/p
en: Make sure you have no local changes: <cmd>git status</cmd>
es_ES: Asegúrese de que no tiene cambios locales: <cmd>git status</cmd>

note: (itstool) path: item/p
en: If the release is for a stable package version, increment the libtool version number in <file>configure.ac</file> (if it exists)
es_ES: Si la publicación es para una versión estable del paquete, incremente el número de versión libtool en <file>configure.ac</file> (si éste existe)

note: (itstool) path: item/p
en: Add an entry to the <file>NEWS</file> file
es_ES: Añada una entrada al archivo <file>NEWS</file>

note: (itstool) path: item/p
en: Run <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> and ensure it succeeds
es_ES: Ejecute <cmd>./autogen.sh &amp;&amp; make &amp;&amp; make install &amp;&amp; make distcheck</cmd> y asegúrese de que termina correctamente

note: (itstool) path: item/p
en: Fix any issues which come up, commit those changes, and restart at step 3
es_ES: Corrija los errores que surjan, confirme esos cambios, y reincide en el paso 3

note: (itstool) path: item/p
en: If <cmd>make distcheck</cmd> finishes with “[archive] is ready for distribution”, run <cmd>git commit -a -m "Release version x.y.z"</cmd> (where ‘x.y.z’ is the package version number)
es_ES: Si <cmd>make distcheck</cmd> finaliza con «El [archivo] está listo para su distribución», ejecute <cmd>git commit -a -m «Versión de la publicación x.y.z»</cmd>

note: (itstool) path: item/p
en: Run <cmd>git push</cmd>
es_ES: Ejecute <cmd>git push</cmd>

note: (itstool) path: item/p
en: If that fails due to other commits having been pushed in the meantime, run <cmd>git pull</cmd> to merge your commit on the branch followed by a second <cmd>git push</cmd>. This is an exception to the GNOME guideline to have a linear Git history (<link xref="version-control#use-of-git"/>). If you prefer to have a linear history, you need to restart at step 1.
es_ES: Si eso no funciona debido a que otros commits se han subido mientras tanto, ejecute <cmd>git pull</cmd> para mezclar su commit en la rama seguida de un segundo <cmd>git push</cmd>. Esta es una excepción a la directriz de GNOME de tener un histórico de Git lineal (<link xref="version-control#use-of-git"/>). Si usted prefiere tener un histórico lineal, es necesario reiniciar en el paso 1.

note: (itstool) path: item/p
en: Tag the release: <cmd>git tag -s x.y.z</cmd> (where ‘x.y.z’ is the package version number)
es_ES: Etiquete la publicación: <cmd>git tag -s x.y.z</cmd> (donde ‘x.y.z’ es el número de versión del paquete)

note: (itstool) path: item/p
en: Run <cmd>git push origin x.y.z</cmd> (where ‘x.y.z’ is the package version number)
es_ES: Ejecute <cmd>git push origin x.y.z</cmd> (donde ‘x.y.z’ es el número de versión del paquete)

note: (itstool) path: section/p
en: The release is now complete, and the post-release version increment can be done:
es_ES: Ahora la publicación está completa, y se puede hacer el incremento de versión posterior a la misma:

note: (itstool) path: item/p
en: Increment the package version number in <file>configure.ac</file>
es_ES: Incremente el número de la versión del paquete en <file>configure.ac</file>

note: (itstool) path: item/p
en: Run <cmd>git commit -a -m "Post-release version increment"</cmd>
es_ES: Ejecute <cmd>git commit -a -m "Post-release version increment"</cmd>

note: (itstool) path: section/p
en: The package archive generated by <cmd>make distcheck</cmd> can now be uploaded to download.gnome.org or distributed in other ways.
es_ES: El archivo de paquete generado por <cmd>make distcheck</cmd> puede subirse ahora a download.gnome.org o distribuirse de otras maneras.

note: (itstool) path: info/desc
en: Good, readable code keeps the project maintainable
es_ES: El código bueno y legible conserva el proyecto mantenible

note: (itstool) path: page/title
en: The Importance of Writing Good Code
es_ES: La importancia de escribir buen código

note: (itstool) path: page/p
en: GNOME is a very ambitious free software project, and it is composed of many software packages that are more or less independent of each other. A lot of the work in GNOME is done by volunteers: although there are many people working on GNOME full-time or part-time for here, volunteers still make up a large percentage of our contributors. Programmers may come and go at any time and they will be able to dedicate different amounts of time to the GNOME project. People’s “real world” responsibilities may change, and this will be reflected in the amount of time that they can devote to GNOME.
es_ES: GNOME es un proyecto de software libre muy ambicioso, y se compone de muchos paquetes de software que son más o menos independientes unos de otros. Una gran parte del trabajo en GNOME se hace mediante voluntarios: aunque hay muchas personas trabajando en GNOME a tiempo completo o a tiempo parcial, los voluntarios siguen constituyendo un gran porcentaje de nuestros colaboradores. Los programadores pueden ir y venir en cualquier momento y serán capaces de dedicar diferentes cantidades de tiempo al proyecto GNOME. Las responsabilidades de la gente del «mundo real» pueden cambiar, y esto se reflejará en la cantidad de tiempo que puedan dedicar a GNOME.

note: (itstool) path: page/p
en: Software development takes long amounts of time and painstaking effort. This is why most part-time volunteers cannot start big projects by themselves; it is much easier and more rewarding to contribute to existing projects, as this yields results that are immediately visible and usable.
es_ES: El desarrollo de software lleva grandes cantidades de tiempo y de esfuerzo minucioso. Por este motivo la mayoría de los voluntarios a tiempo parcial no pueden comenzar grandes proyectos por sí mismos; es mucho más fácil y gratificante contribuir a proyectos existentes, ya que estos producen resultados que son visibles y utilizables inmediatamente.

note: (itstool) path: page/p
en: Thus, we conclude that it is very important for existing projects to make it as easy as possible for people to contribute to them. One way of doing this is by making sure that programs are easy to read, understand, modify, and maintain.
es_ES: Por lo tanto, llegamos a la conclusión de que es muy importante para los proyectos existentes hacer lo más fácil posible a la gente contribuir en ellos. Una forma de hacer esto es asegurándose de que los programas son fáciles de leer, comprender, modificar y mantener.

note: (itstool) path: page/p
en: Messy code is hard to read, and people may lose interest if they cannot decipher what the code tries to do. Also, it is important that programmers be able to understand the code quickly so that they can start contributing with bug fixes and enhancements in a short amount of time. Source code is a form of <em>communication</em>, and it is more for people than for computers. Just as someone would not like to read a novel with spelling errors, bad grammar, and sloppy punctuation, programmers should strive to write good code that is easy to understand and modify by others.
es_ES: El código desordenado es difícil de leer, y la gente puede perder el interés si no puede descifrar qué trata de hacer. También es importante que los programadores puedan entender el código rápidamente para que puedan empezar a contribuir con correcciones de errores y mejoras en un período de tiempo corto. El código fuente es una forma de <em>comunicación</em>, y es más para la gente que para los ordenadores. Igual que a alguien no le gustaría leer una novela con errores ortográficos, mala gramática, y una puntuación descuidada, los programadores deberían esforzarse en escribir buen código que sea fácil de entender y modificar por otros.

note: (itstool) path: page/p
en: The following are some important qualities of good code:
es_ES: Las siguientes son algunas cualidades importantes de buen código:

note: (itstool) path: item/title
en: Cleanliness
es_ES: Limpieza

note: (itstool) path: item/p
en: Clean code is easy to read with minimum effort. This lets people start to understand it easily. This includes the coding style itself (brace placement, indentation, variable names), and the actual control flow of the code.
es_ES: El código limpio es fácil de leer con el mínimo esfuerzo. Esto permite a la gente empezar a entenderlo fácilmente. Esto incluye el estilo de codificación en sí (el lugar de las llaves, la sangría, los nombres de variables), y el control del flujo real del código.

note: (itstool) path: item/title
en: Consistency
es_ES: Consistencia

note: (itstool) path: item/p
en: Consistent code makes it easy for people to understand how a program works. When reading consistent code, one subconsciously forms a number of assumptions and expectations about how the code works, so it is easier and safer to make modifications to it. Code that <em>looks</em> the same in two places should <em>work</em> the same, too.
es_ES: El código consistente hace fácil a la gente entender cómo funciona un programa. Cuando se lee código consistente, uno forma inconscientemente una serie de suposiciones y expectativas acerca de cómo funciona el código, por lo que es más fácil y más seguro realizar modificaciones en él. El código que <em>parece</em> el mismo en dos sitios debería <em>funcionar</em> igual, también.

note: (itstool) path: item/title
en: Extensibility
es_ES: Extensible

note: (itstool) path: item/p
en: General-purpose code is easier to reuse and modify than very specific code with lots of hardcoded assumptions. When someone wants to add a new feature to a program, it will obviously be easier to do so if the code was designed to be extensible from the beginning. Code that was not written this way may lead people into having to implement ugly hacks to add features.
es_ES: El código de propósito general es más fácil de reutilizar y modificar que el código muy específico con muchas suposiciones en codificación fija. Cuando alguien quiere añadir una nueva característica al programa, obviamente será más fácil hacerlo si el código se diseñó para ser extensible desde el principio. El código que no se escribió de esta manera puede llevar a la gente a tener que implementar hacks feos para añadir características.

note: (itstool) path: item/title
en: Correctness
es_ES: Corrección

note: (itstool) path: item/p
en: Finally, code that is designed to be correct lets people spend less time worrying about bugs, and more time enhancing the features of a program. Users also appreciate correct code, since nobody likes software that crashes. Code that is written for correctness and safety (i.e. code that explicitly tries to ensure that the program remains in a consistent state) prevents many kinds of silly bugs.
es_ES: Finalmente, el código que está diseñado para ser correcto permite a la gente emplear menos tiempo preocupándose por errores, y más tiempo mejorando las características de un programa. Los usuarios también aprecian el código correcto, ya que a nadie le gusta el software que se rompe. El código que se escribe para la corrección y la seguridad (es decir, código que intenta explícitamente asegurar que el programa permanece en un estado consistente) previene muchas clases de errores tontos.

note: (itstool) path: section/title
en: Book References
es_ES: Referencias del libro

note: (itstool) path: item/p
en: <link href="http://www.cc2e.com">Code Complete</link>, by Steve McConnell.
es_ES: <link href="http://www.cc2e.com">Code Complete</link>, por Steve McConnell.

note: (itstool) path: item/p
en: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, by Martin Fowler.
es_ES: <link href="http://martinfowler.com/books/refactoring.html"> Refactoring: Improving the Design of Existing Code </link>, por Martin Fowler.

note: (itstool) path: item/p
en: <link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>, by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.
es_ES: <link href="https://en.wikipedia.org/wiki/Design_Patterns"> Design Patterns: Elements of Reusable Object-Oriented Software </link>, por Erich Gamma, Richard Helm, Ralph Johnson y John Vlissides.

note: (itstool) path: item/p
en: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>, by Arthur Riel.
es_ES: <link href="http://astore.amazon.com/gnomestore-20/detail/020163385X"> Object-Oriented Design Heuristics </link>, por Arthur Riel.
