Algunas correcciones

ktowen · ktowen · commit 13b9aa531ef3 · 2020-08-06T09:05:14.000-04:00
diff --git a/dictionaries/howto_sockets.txt b/dictionaries/howto_sockets.txt
@@ -0,0 +1,7 @@
+Motorola
+Posix
+buffers
+leíble
+multiplexar
+pruébalo
+usable
diff --git a/howto/sockets.po b/howto/sockets.po
@@ -9,7 +9,7 @@ msgstr ""
 "Project-Id-Version: Python 3.8\n"
 "Report-Msgid-Bugs-To: \n"
 "POT-Creation-Date: 2019-05-06 11:59-0400\n"
-"PO-Revision-Date: 2020-08-05 19:57-0400\n"
+"PO-Revision-Date: 2020-08-06 09:04-0400\n"
 "Language-Team: python-doc-es\n"
 "MIME-Version: 1.0\n"
 "Content-Type: text/plain; charset=UTF-8\n"
@@ -21,7 +21,7 @@ msgstr ""
 
 #: ../Doc/howto/sockets.rst:5
 msgid "Socket Programming HOWTO"
-msgstr "*HOW TO* - Programación con sockets"
+msgstr "HOW TO - Programación con sockets"
 
 #: ../Doc/howto/sockets.rst:0
 msgid "Author"
@@ -85,7 +85,7 @@ msgstr ""
 "Parte del problema para entenderlos es que \"socket\" puede significar un número "
 "de cosas ligeramente diferentes dependiendo del contexto. Entonces, primero "
 "vamos a hacer una distinción entre sockets \"cliente\" - un extremo de una "
-"conversación, y un socket \"servidor\", que es mas como una central de "
+"conversación, y un socket \"servidor\", que es más como una central de "
 "teléfonos. La aplicación cliente (tu navegador, por ejemplo) usa sockets "
 "\"cliente\" exclusivamente; el servidor web con quien se está comunicando usa "
 "sockets \"cliente\" y \"servidor\"."
@@ -148,7 +148,7 @@ msgid ""
 "What happens in the web server is a bit more complex. First, the web server "
 "creates a \"server socket\"::"
 msgstr ""
-"Lo que sucede en el servidor web es un poco mas complejo. Primero, el servidor "
+"Lo que sucede en el servidor web es un poco más complejo. Primero, el servidor "
 "web crea un \"socket servidor\":"
 
 #: ../Doc/howto/sockets.rst:80
@@ -212,14 +212,14 @@ msgid ""
 msgstr ""
 "Existen en realidad 3 maneras generales en las cuales este bucle puede funcionar "
 "- despachar un hilo para manejar ``clientsocket``, crear un proceso nuevo para "
-"manejar ``clientsocket`` o reestructurar esta app para usar sockets no "
+"manejar ``clientsocket`` o reestructurar esta aplicación para usar sockets no "
 "bloqueantes y multiplexar entre nuestro \"socket servidor\" y cualquier "
 "``clientsocket`` activo usando ``select``. Más sobre esto después. Lo importante "
 "a entender ahora es: esto es *todo* lo que un \"socket servidor hace\". No manda "
 "ningún dato. No recibe ningún dato. Solo produce \"sockets clientes\". Cada "
 "``clientsocket`` es creado en respuesta a algún otro \"socket cliente\" que hace "
 "``connect()`` al host y al puerto al que estamos vinculados. Tan pronto como "
-"hemos credo ese ``clientsocket`` volvemos a escuchar por mas conexiones. Los dos "
+"hemos credo ese ``clientsocket`` volvemos a escuchar por más conexiones. Los dos "
 "\"clientes\" son libres de \"conversar\" entre ellos - están usando algún puerto "
 "asignado dinámicamente que será reciclado cuando la conversación termine."
 
@@ -284,10 +284,10 @@ msgstr ""
 "archivo y usar ``read`` y ``write``. Esta última es la forma en que Java "
 "presenta sus sockets. No voy a hablar acerca de eso aquí, excepto para "
 "advertirte que necesitas usar ``flush`` en los sockets. Estos son archivos en "
-"búfer, y un error común es usar ``write`` para escribir algo y luego usar "
+"buffer, y un error común es usar ``write`` para escribir algo y luego usar "
 "``read`` para leer la respuesta. Sin usar ``flush`` en este caso, puedes "
 "terminar esperando la respuesta por siempre porque la petición estaría aún en el "
-"búfer de salida."
+"buffer de salida."
 
 #: ../Doc/howto/sockets.rst:152
 msgid ""
@@ -303,7 +303,7 @@ msgstr ""
 "en los buffers de red. Ellos no manejan necesariamente todos los bytes que se "
 "les entrega (o espera de ellos), porque su enfoque principal es manejar los "
 "buffers de red. En general, ellos retornan cuando los buffers de red asociados "
-"se han llenado (``send``) o vaciado (``recv``). Luego ellso dicen cuántos bytes "
+"se han llenado (``send``) o vaciado (``recv``). Luego ellos dicen cuántos bytes "
 "manejaron. Es *tu* responsabilidad llamarlos nuevamente hasta que su mensaje "
 "haya sido tratado por completo."
 
@@ -360,8 +360,8 @@ msgid ""
 "Assuming you don't want to end the connection, the simplest solution is a fixed "
 "length message::"
 msgstr ""
-"Asumiendo que no quieres terminar la conexión, la solución mas simple es un "
-"mansaje de longitud fija:"
+"Asumiendo que no quieres terminar la conexión, la solución más simple es un "
+"mensaje de longitud fija:"
 
 #: ../Doc/howto/sockets.rst:217
 msgid ""
@@ -559,10 +559,10 @@ msgstr ""
 "lado se apaga inesperadamente (sin llamar a ``close``). Tu socket es probable "
 "que se cuelgue. TCP es un protocolo confiable, y va a esperar un largo, largo "
 "tiempo antes de rendirse con una conexión. Si estás usando hilos, todo el hilo "
-"esta esencialmente muerto. No hay mucho que puedas hacer respecto a eso. A menos "
+"está esencialmente muerto. No hay mucho que puedas hacer respecto a eso. A menos "
 "que no estés haciendo algo tonto, como mantener un bloqueo mientras se realiza "
 "una lectura bloqueante, el hilo realmente no estará consumiendo muchos recursos. "
-"*No* trates de matar el hilo - parte de la razón por la que los hilos son mas "
+"*No* trates de matar el hilo - parte de la razón por la que los hilos son más "
 "eficientes que los procesos es que evitan la complicación asociada con el "
 "reciclaje automático de recursos. En otras palabras, si te las arreglas para "
 "matar el hilo, es muy probable que todo el proceso termine arruinado."
@@ -669,12 +669,12 @@ msgid ""
 "(Actually, any reasonably healthy socket will return as writable - it just means "
 "outbound network buffer space is available.)"
 msgstr ""
-"Si un socket esta en la lista retornada de los leíbles, puedes estar tan-seguro-"
+"Si un socket está en la lista retornada de los leíbles, puedes estar tan-seguro-"
 "como-podrías-estarlo-en-este-negocio que una llamada a ``recv`` en este socket "
 "va a devolver *algo*. La misma idea se aplica a la lista de escribibles. Serás "
 "capaz de mandar *algo*. Tal vez no todo lo que quieras, pero *algo* es mejor que "
 "nada. (Realmente, cualquier socket socket razonablemente saludable va a retornar "
-"como escribible - eso solo significa que el espacio de salida del búfer de red "
+"como escribible - eso solo significa que el espacio de salida del buffer de red "
 "está disponible)"
 
 #: ../Doc/howto/sockets.rst:366
@@ -689,7 +689,7 @@ msgstr ""
 "retorna en la lista de leíbles, una llamada a ``acept`` va a funcionar (casi "
 "seguro). Se has creado un nuevo socket para llamar a ``conect`` para conectarte "
 "con otro, ponlo en la lista de *potenciales escribibles*. Si retorna en la lista "
-"de escribibles, tienes una buena oportunidad de que este conectado."
+"de escribibles, tienes una buena oportunidad de que esté conectado."
 
 #: ../Doc/howto/sockets.rst:372
 msgid ""
@@ -700,8 +700,8 @@ msgid ""
 msgstr ""
 "Realmente, ``select`` puede ser útil incluso con sockets bloqueantes. Es una "
 "manera de determinar si vas a bloquear - el socket retorna como leíble cuando "
-"hay algo en el búfer. Sin embargo, esto aun no sirve de ayuda con el problema de "
-"determinar si el otro extremo terminó, o solo está ocupado con otra cosa."
+"hay algo en el buffer. Sin embargo, esto aun no sirve de ayuda con el problema "
+"de determinar si el otro extremo terminó, o solo está ocupado con otra cosa."
 
 #: ../Doc/howto/sockets.rst:377
 msgid ""
