documentación oficial de Python al Español!

contribución, queremos señalar algunos

:ref:`lineamientos generales <a-tener-en-cuenta>`.

Antes de comenzar

.. image:: fork.png

:alt: botón fork

#. (Opcional) Crea un entorno virtual y actívalo::

#. (Opcional) Instala los requerimientos del proyecto::

¡Comienza a traducir!

#. Selecciona un :ref:`archivo para traducir <que-archivo-traducir>`.

#. Verifica que estás en la rama principal del repositorio, **3.8** (esto es muy

importante para evitar crear una nueva rama a partir de una traducción

anterior)::

ejemplo, si vas a trabajar en el archivo ``library/glosario.po``, usa un nombre

GitHub (No olvides añadir tu nombre al archivo ``TRANSLATORS``)::

Mira los mensajes que el último comando imprimirá por pantalla,

pues encontrarás un enlace para abrir un nuevo Pull-request directamente.

:ref:`mantener actualizada <mantener-actualizada>` tu copia local antes

de realizar el *Pull Request*.

.. _que-archivo-traducir:

.. _a-tener-en-cuenta:

* Esta traducción es mantenida por **personas de todo el mundo** que hablan el

idioma Español. No queremos atarla a ninguna región en particular y creemos

que es un valor extra la diversidad de la misma. Vas a encontrar secciones

con diferentes tonalidades de países, regiones o estilos. Lo único que pedimos

es **consistencia** dentro de un mismo módulo o sección (es decir no cambiar de

estilo de un párrafo a otro, por ejemplo) y siempre intentar que la persona del

otro lado pueda entender lo que estamos escribiendo (no usar lunfardo o

regionalismos muy propios de un único lugar).

* En muchos casos el **mejor criterio** es pensar en el vocabulario que utilizamos

cuando le explicamos a otra persona, o en el trabajo. En muchas ocasiones la

versión en inglés o “spanglish” de la palabra es mucho mejor que decir “git

unir” (para git merge).

* Siempre vas a tener una **revisión de lo que propongas** y en ese intercambio otras

personas van a ayudarte a destrabar las dudas que tengas.

* Colaborar **haciendo revisiones** también es muy muy importante, así que si

tienes un rato libre puedes comenzar por mirar los PRs pendientes de revisar.

(mira la :doc:`Guía del revisor <reviewers-guide>`)

* La documentación es ENORME, cualquier traba que encuentres siempre puedes

marcar el texto como **"fuzzy"** o para revisar en el futuro.

No pierdas horas buscando la palabra perfecta.

* **No debes** traducir el contenido de ``:ref:...``, ``:term:...``, ``:dfn:...``, etc.

* Puedes revisar las :doc:`Preguntas Frecuentes <faq>` para leer sobre problemas conocidos.

* Si **traduces un título que es un enlace**, por favor traduce el link también (por

* Tenemos una :doc:`Memoria de Traducción <translation-memory>`, que usamos para tener

consistencia con algunos términos.

* Si tienes una **duda sobre una palabra o término**, escríbelo como mejor suene

* Te recomendamos abrir una **Pull Request aunque sea en formato borrador** (marcada

* Último pero no menos importante, **divertite y contá con la ayuda de todes**. Te

esperamos en nuestro chat en telegram. ¡Gracias!

Es recomendable mantener actualizada nuestra copia local para evitar

posibles conflictos entre los archivos que trabajamos y la última versión disponible

en el repositorio remoto.

Primero, necesitamos bajar los cambios de *upstream* (es el nombre que asignamos al

¿Son importantes los dobles espacios en el original?

No.

En realidad, no tienen ningún efecto. Sphinx se da cuenta automáticamente de esto y simplemente

deja un solo espacio en la versión final. Así que, no te preocupes si ves dos espacios juntos.

Si estás interesada en saber más sobré "¿Por qué se usan dobles espacios?" puedes leer este artículo:

`How Many Spaces Should Be After a Period? <https://www.instructionalsolutions.com/blog/one-space-vs-two-after-period>`_

¿Puedo agregar "estilo de código" a los nombres de las funciones/métodos/clases/etc?

No.

Si aparece el nombre de una función (por ejemplo, "IncrementalParser") en el original y no tiene ningún estilo asociado

(no está en cursiva, ni en negrita ni en estilo de código), aunque sientas la tentación de ponerla como

``IncrementalParser``, no debes hacerlo.

En principio, no debemos cambiar el formato de estas palabras. Si está con asteriscos, lo dejamos con asteriscos.

Si está con backticks, lo dejamos con los backticks, etc. Si realmente crees que es un error y debería

estar con un formato distinto, debes reportarlo en el repositorio de CPython.

Antes que nada, queremos compartir contigo `unos videos`_ que uno de nuestros colaboradores ha preparado donde se explica el resumen del proceso a través de un ejemplo.

Asimismo, si nunca has hecho una revisión pero ya has colaborado con el proyecto, te recomendamos que pruebes esta otra manera de colaborar, ya que permite ponerse en el lugar de otra persona, y muchas veces ayuda a mejorar las traducciones propias.

.. _`unos videos`: https://www.youtube.com/watch?v=uIaQMTuwtoU&list=PLma583Z70SlztPF8SitlWJZx3SW1aAePk&index=3&t=7s&ab_channel=Cristi%C3%A1nMaureira-Fredes

Tres razones por las que puede fallar el *build* de Travis:

``powrap`` falla

.. image:: powrap_fail.png

Para facilitar la comparación de ficheros se emplea este programa que va a hacer que todas las líneas tengan el mismo tamaño. Solucionar este problema en nuestra traducción es muy sencillo, solo hay que instalar la herramienta powrap en nuestro entorno y ejecutar el comando ``powrap nuestro_fichero.po``

``pospell`` falla

Los fallos en pospell pueden ser variados y según con que nos encontremos tenemos que actuar de una manera u otra. En principio es un chequeo de ortografía contra un diccionario de español, por lo que nos va a fallar tanto si usamos palabras en otro idioma, como si usamos palabras en español mal escritas como si usamos palabras que simplemente no están en el diccionario. Por ejemplo:

.. image:: pospell_fallo_spelling.png

En este primer caso simplemente hay un error en la ortografía por lo que solucionarlo en nuestra traducción será lo únicoque tengamos que hacer.

.. image:: pospell_warning_and_english_words.png

En este segundo, en cambio, vemos un par de cosas más interesantes. En primer lugar, tenemos un warning de rst, donde nos da un error porque unas comillas no han sido reconocidas como final de una palabra. Si te fijas en el texto esto ocurre donde están los paréntesis pegados a la expresión entre comillas dobles SNDCTL_DSP_SYNC. Añadir un espacio allí solucionará nuestro problema. Por otro lado, nos lanza una serie de palabras que han fallado en pospell, pero como vemos, son o bien términos técnicos, o nombres en inglés (en este caso posiblemente parte de un nombre propio) y una palabra que está correctamente escrita en español pero es un poco técnica. Por tanto, en este caso no queremos cambiarlas en nuestra traducción, sino que queremos que sean una excepción en el chequeo de pospell. Para ello, lo que debemos hacer es o bien crear o bien incluir (si ya está creado) en un diccionario llamado como nuestro fichero y que se emplace en la carpeta dictionaries las palabras que deben ser una excepción. Por ejemplo, los diccionarios para el fichero clinic o argparse los encontramos dentro de ./dictionaries como howto_clinic.txt y library_argparse.txt. Cuando se haga el build se tendrán en cuenta estas excepciones y no tendremos ese error de pospell.

Sphinx falla:

Durante la renderización de la documentación hay toda una serie de referencias cruzadas, que deben permanecer igual en español que en inglés. Un fallo habitual es el siguiente:

.. image:: sphinx_warnings_example_inconsistent_terms.png

Indica que alguna de las referencias falta en la traducción. Lo más probable es que al traducir se haya cambiado algo de la sintaxis particular como las comillas, y por eso no esté siendo reconocida.