Doc/translation-memory.rst

Doc/upgrade-python-version.rst

locales/

__pycache__/

env/

build/

.idea/

/translation-memory.po

/locale/

- Colaborar haciendo reviews también es muy muy importante, así que si

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

(mira la `Guía del revisor`_)

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

esperamos en nuestro chat en telegram. ¡Gracias!

#. En la descripción de la *Pull Request* escribe ``Closes #<número de issue>``

(así se cierra automáticamente cuando se hace *merge*)

..note::

Si hace tiempo que venis trabajando en una traducción es importante

:ref:`mantener actualizada<mantener-actualizada>` tu copia local antes de realizar el *Pull Request*.

¿Qué archivo traducir?

tiene una traducción al Español en la barra de la izquierda. Suelen estar

bastante bien explicados.

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

como draft) desde los primeros commits de la traducción de tu fichero. De esta

forma, puedes recibir feedback desde el principio que puedes aplicar al resto

de la traducción, y probar el build más a menudo.

..note::

.. _nuestro canal de Telegram:https://t.me/python_docs_es

.. _Memoria de traducción:

.. _Guía del revisor:

.. _la traducción al Portugués:https://docs.python.org/pt-br/3/

.. _lista de issues en GitHub:

Una vez instalado, para chequear el fichero .po sobre el que estás trabajando,

ejecuta desde el directorio principal del repo::

pospell emplea la herramienta de diccionarios hunspell. Si pospell falla dando

como error que no tiene hunspell instalado, lo puedes instalar así:

pero por el momento el chequeo que hacemos es con los diccionarios es_AR y es_ES.

¿Cómo agrego una palabra al diccionario?

Si ``pospell`` falla diciendo que no conoce una palabra, pero estamos seguros que esa palabra está bien escrita,

debemos agregarla al diccionario que ``pospell`` usa internamente para comprobar las palabras.

Para eso debes editar (o crear, si no existe) el archivo ``<archivopo>.txt`` dentro del direcorio ``dictionaries``

y agregar esa palabra al final de este archivo.

Nota que debes reemplazar ``<archivopo>`` por el nombre del archivo que estés traduciendo.

Por ejemplo, si estás traduciendo ``library/decimal.po``, debes editar/crear el archivos ``dictionaries/library_decimal.txt``.

¿Cómo puedo configurar git para manejar correctamente los finales de línea en Windows?

Desactivar "Smart Quotes" y "Smart Dashes"

..tip::

Este comando te puede ayudar a cambiar todas las comillas::

¿Qué parte de ``:ref:`` debo traducir?

Y luego accediendo a http://localhost:8000/

.. _mantener-actualizada:

¿Cómo actualizar mi copia local del repositorio?

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

repositorio principal de la traducción). Se hace de la siguiente manera::

Luego nos vamos a nuestra rama local, confirmamos e impactamos esos cambios::

¡Eso es todo!

¿Tienen una lista de correo?

..note::

Esta lista se actualiza automáticamente cuando Pull Requests se *mergean* a la rama ``3.8``.

Estas listas se actualiza automáticamente cuando Pull Requests se *mergean* a la rama ``3.8``.

En progreso

Muestra los porcentajes completados por directorio y solo los archivos que no están al 100%.

..runblock::console

$ potodo --offline --path .

Completados

Lista todos los archivos con un porcentaje de traducción mayor al 90% (para contemplar los que tienen fuzzy).

..runblock::console

$ python scripts/completed_files.py

Guía para revisar una traducción

El costado humano

Teniendo en cuenta que todes somos voluntaries en este proyecto, es importante que la forma de comunicarnos sea clara, concisa y amable. Como revisor/a, ayudarás a voluntaries de diferentes culturas y lugares del mundo para que su traducción sea lo más acertada posible y podamos acercar Python a las comunidades de habla hispana. Recuerda que del otro lado de un PR hay una persona que ha dedicado tiempo y esfuerzo; es por eso es la forma en que le des una devolución sobre su trabajo influirá en su actitud hacia el proyecto…¡y en sus ganas de seguir participando de nuestra comunidad!

Aquí te dejamos algunos *tips* para que tu devolución sea constructiva y genuina:

* Siempre deja un comentario en la PR que deje una conclusión general de tu devolución para dejarle claro a les traductores qué necesita modificación y qué no. Recuerda siempre comenzar reconociendo los aspectos positivos del trabajo de la otra persona y luego puedes agregar comentarios/sugerencias sobre la traducción.

El costado práctico

La devolución deberá ser acertada para transmitir el mensaje que necesitamos que llegue; de esta forma, les traductores podrán revisar su trabajo y saber qué necesitan hacer para mejorarlo.

No olvides que esto se trata de una traducción técnica y como tal, el objetivo es que, básicamente, la persona que la lea pueda entender cómo usar Python. Es por esto que, si bien es importante que la sintaxis sea correcta, el objetivo no es hacer una revisión intensiva del uso del español, a menos que la forma en que se expresó la idea imposibilite que otre la entienda.

Para esto, Github te ofrece opciones para afrontar una PR (ver botón *Review Changes* arriba a la derecha de los archivos modificados por les traductores):

* *Comment*: Puedes dejar un comentario sin necesariamente aprobar la PR. Asegúrate de hacerlo con claridad para que quien tradujo sepa que debe modificar algunas cosas antes de que su PR sea aprobada.

* *Approve*: Dejar esta opción solo para PRs que no necesitan modificación alguna o que solo tengan pocas faltas de ortografía o errores de tipeo, o algún error que no genere un conflicto mayor en la traducción y en su integración al repositorio.

* *Request Changes*: Utiliza esta opción cuando la traducción necesita varias modificaciones que afectan su integración al repositorio. En este caso también asegúrate de que tu mensaje sea claro y amable para acompañar al traductor en el proceso de modificar y lograr que la PR se apruebe.

*Tips*

* PRs de más de 1000 líneas: Te sugerimos hacer un comentario al principio del PR para indicar hasta qué línea haz hecho el review y qué hay que revisar hasta ese hito. También si tú mismo vas a continuar la review, pero no puedes hacerla de una sola vez, es útil para saber donde retomar tu trabajo.

* El uso de la opción "Needs work" en poedit genera en la línea anterior al párrafo un comentario "#, fuzzy" para que el traductor revise esa línea. Se puede usar cuando la traducción necesita revisión y en ese momento no puedes sugerir una traducción alternativa. Ten en cuenta que los párrafos con esa marca no aparecerán traducidos en el build. Como revisor, también podrías incluir ese comentario tu mismo como sugerencia.

* Al igual que cuando uno traduce, en el proceso de revisión puedes consultar y emplear las herramientas que tenemos. Por ejemplo, si no estás seguro sobre la traducción de un término sobre el que puede que ya hayamos tomado una decisión consensuada, puedes consultar la memoria de traducción [,](https://github.com/python/python-docs-es/blob/3.8/.overrides/translation-memory.rst) usar `scripts/find_in_po.py` o incluso comentarlo en nuestro grupo de Telegram.

El costado técnico

Al revisar una traducción, deberás tener en cuenta ciertos aspectos propios de una traducción técnica de esta índole. Además de que debe entenderse el texto en español y que debes respetar el contenido de la documentación original (ver "A tener en cuenta" en la `Guía para contribuir en la traducción<https://python-docs-es.readthedocs.io/es/3.8/CONTRIBUTING.html>`_), contamos con herramientas en este proyecto que pueden fallar en ciertos casos, y que como revisor/a deberás tener en cuenta.

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

* `powrap` falla

* `pospell` falla

* Dict está duplicado

* Sphinx falla

Dividimos esta sección en dos partes, los términos que se traducen y los que mantenemos el original.

Éstas son las palabras que hemos coordinado hasta el momento:

auditing event

evento de auditoría ``library/tempfile`` and many others

awaitable

aguardable ``glossary``

slash and backslash

barra y barra invertida ``c-api``,``tutorial``,``library/functions.po``

built-in

incorporada ``glossary.po``

built-in exceptions

excepciones predefinidas ``tutorial/errors.po``

bytecodes

queda igual ``glossary.po``

callable

invocable ``glossary.po``, ``library/functions.po``

deallocated

desalojable ``glossary.po``

docstring

docstring. ``library/idle.po``

key

clave

keyword argument

argumento por palabra clave / argumento de palabra clave

handler

gestor ``tutorial/errors.po``

handle exception

gestionar [una] excepción. ``tutorial/inputoutput.po``

gestionar excepciones

i. e.

en otras palabras. ``library/sqlite3.po``

in-place, in place

in situ. Aunque estrictamente no es español, su uso es generalizado.

library

biblioteca. ``library/sqlite3.po``

list comprehension / list comprehensions

lista por comprensión / listas por comprensión.

locale

Configuración regional. ``library/functions.po`` and others

helper function

función auxiliar ``library/typing.po``

loop

bucle ``tutorial/controlflow.po``

named tuple.

tupla nombrada ``glossary.po``

overload, overloading

sobrecargar, sobrecarga

override, overriding

sobreescribir, sobreescritura

path

ruta ``glossary.po``

release

version ``HOWTO``

return / returns

retorna / retornar ``library/sqlite3.po`` and many others

return type

tipo de retorno ``library/typing.po``

runtime

tiempo de ejecución ``tutorial/classes.po``

slice

segmento ``datamodel.po``

slicing

segmentación ``datamodel.po``

static type checker

Validador estático de tipos

Notas: en general mantener la mayúscula aunque no es necesario,

usar validación cuando se refiera a la acción y no al agente.

Notas: mantener la mayúscula, usar validación cuando se refiera a la acción y no al agente.

string

cadena de caracteres ``datamodel.po``

strings

cadenas de caracteres ``datamodel.po``

third-party

de terceros ``library/typing.po``

es algo accesorio, un comentario, y type hint implica que el Validador hará comprobaciones

underscore

guión bajo ``glossary.po``

guión bajo ``glossary.po``

widget

widget ``library/tkinter``

Términos que no se traducen

``\*[^*]+\*``

Reglas de estilo

rev:master

hooks:

-id:powrap

-repo:local

hooks:

-id:merge-dicts

name:merge-dicts

entry:./scripts/merge-dicts.sh

language:script

-repo:https://github.com/humitos/pospell

rev:pre-commit

hooks:

-id:pospell

args:['--personal-dict', 'dict', '--modified', '--language', 'es_ES', '--language', 'es_AR']

args:['--personal-dict', 'dict.txt', '--modified', '--language', 'es_ES', '--language', 'es_AR']

install:

-requirements:requirements.txt

formats:

-pdf

formats:[]

submodules:

include:all

-powrap --version

script:

-powrap --check --quiet **/*.po

-pospell -p dict -l es_AR -l es_ES **/*.po

-make dict_dups

-make build

-awk 1 dict dictionaries/*.txt > dict.txt

-pospell -p dict.txt -l es_AR -l es_ES **/*.po

-pip install -q -r requirements.txt

-PYTHONWARNINGS=ignore::FutureWarning sphinx-build -j auto -W --keep-going -b html -d cpython/Doc/_build/doctree -D language=es . cpython/Doc/_build/html

branches:

only:

-/^3\.\d$/