-## Traducir o proponer una lección nueva
+Estas directrices han sido desarrolladas para ayudarte a entender el proceso de creación de un tutorial para *Programming Historian* en Español. Incluyen detalles prácticos sobre el proceso de redacción de un tutorial, así como indicaciones sobre el flujo de trabajo y el proceso de revisión entre pares. Si en algún momento hay algo que no te queda claro, por favor envía un correo electrónico a {% include managing-editor.html lang=page.lang %}.
-Si quieres traducir una lección, o si tienes una idea para una lección nueva o ya has escrito un tutorial que crees que puede adaptarse a *The Programming Historian en español*, completa un [formulario de propuesta de tutorial](/assets/forms/Formulario.Consulta.Leccion.txt) y contacta con {% include managing-editor.html lang=page.lang %}. Cuanto antes te pongas en contacto con nosotros, mucho mejor; de esta manera, te ayudaremos a plantear adecuadamente tu contribución, teniendo en cuenta el público objetivo y el nivel de conocimientos necesarios. También te asignaremos un editor para ayudarte a resolver dudas y a desarrollar la lección de la mejor manera.
+## Paso 1: Proponer una nueva lección
-**¿Qué lecciones traducir?** Si quieres traducir una lección, por favor, revisa la lista de [traducciones pendientes] y ponte en contacto con nosotros. Buscamos traducciones rigurosas, de lectura amena y que, además, tengan en cuenta el contexto de España y América Latina y los recursos disponibles en lengua española.
-
-**¿Qué tipo de lección queremos?** Aceptamos tutoriales relevantes para las humanidades, dirigidos a cualquier nivel de aptitud técnica y experiencia, que se centren en un problema o proceso, que puedan ser sostenibles a largo plazo y que estén dirigidos a una audiencia global. El alcance y la longitud del tutorial han de corresponderse con la complejidad de la tarea que se enseña. Los tutoriales no deben exceder las 8.000 palabras (incluyendo el código) sin el permiso explícito del editor y que se otorgará únicamente en circunstancias excepcionales. Esperamos que la mayoría de las lecciones tengan entre 4.000 y 6.000 palabras. Puede que pidamos dividir en varios tutoriales las lecciones más largas.
-
-**En resumen, aceptamos todo tipo de propuestas.** Consulta nuestras [lecciones ya publicadas], lee nuestras [directrices para revisores] o explora las [lecciones actualmente en desarrollo](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons) para hacerte una mejor idea de lo que publicamos. Animamos al envío de propuestas de lecciones sobre temas ya cubiertos o en desarrollo, siempre que la lección nueva haga una contribución propia.
-
-A fin de que nuestras lecciones sean sostenibles a largo plazo, se anima a los autores a proponer tutoriales que no dependan de un programa o de una interfaz especfica. De lo contrario, los tutoriales dejarían de ser estables y necesitarían cambios con cada actualización. En aras de una mayor conservación, es mejor enseñar conceptos que a 'clicar sobre un botón X'.
-
-Tras la aprobación de tu propuesta, uno de nuestros editores creará un tíquet "Propuesta" en nuestro [repositorio][ph-submissions], en donde se detallará el título provisional y los objetivos de la lección. Este tíquet sirve para documentar el progreso realizado durante la escritura de la lección. Para evitar que se acumulen las lecciones en fase de escritura, te pedimos que entregues tu texto al cabo de 90 días tras la aprobación.
-
-
-
-# Escribir y dar formato
-
-*The Programming Historian en español* se hospeda en [GitHub](http://github.com), una plataforma para mantener archivos y revisar cambios. Se utilizan por lo general para almacenar archivos de código pero también ofrece una buena manera de mantener un recurso en abierto como *The Programming historian en español*. En concreto, nuestrio sitio utiliza [GitHub Pages] para acceder a los archivos de texto y transformarlos en una web.
-
-Esto implica que pidamos a los traductores y autores seguir una serie de requisitos, que no son meramente estilísticos, sino necesarios para publicar las lecciones. **Aunque estos requisitos técnicos puedan ser nuevos para ti, estamos aquí para ayudarte en todo momento y para que aprendas las tecnologías necesarias a medida que avanzas.**
-
-Ten en cuenta que, como proyecto impulsado por voluntarios, esperamos atención al detalle.
-
-## Utiliza un archivo de texto plano
-
-Puesto que nuestro sitio web se publica mediante [GitHub Pages](https://pages.github.com), **las lecciones deben escribirse en texto plano**, con el programa de edición que prefieras. *Los editores de texto se diferencian de manera distintiva de los procesadores de texto tradicionales como MS Word*. Es muy recomendable utilizar [Atom](https://atom.io/), disponible para Mac o Windows. Para Mac, recomendamos editores de texto gratuitos como [TextWrangler] o TextEdit (este último ya va incluido en Mac OS X). Para Windows, puedes usar Notepad o la versión mejorada [Notepad++].
-
-El editor de textos que elijas no es relevante pero, por favor, comienza tu traducción o tutorial en texto plano para evitar problemas más tarde. No dudes en contactar con algún miembro de nuestro [equipo](/es/equipo-de-proyecto) si tienes preguntas o dudas.
-
-Se pide a los autores que usen el [Manual de estilo de Chicago](https://es.wikipedia.org/wiki/Manual_de_estilo_de_Chicago) para el formateo de las notas situadas al final de la lección.
-
-## Escribe en Markdown
-**Todas las traducciones y lecciones nuevas deben estar escritas en Markdown**. Markdow es un lenguaje de marcado muy sencillo que se puede escribir con un editor de textos (tal y como se ha explicado más arriba, no utilices un procesador como MS Word u Open Office). [GitHub Pages] utiliza [Jekyll](http://jekyllrb.com/), que transforma de manera automática los archivos Markdown en archivos HTML para que se visualicen en el navegador. Esta página, por ejemplo, está escrita en Markdown; puedes comprobarlo tú mismo inspeccionado el archivo en [GitHub](https://github.com/programminghistorian/jekyll/blob/gh-pages/es/guia-para-autores.md).
-
-Los recursos y tutoriales siguientes contienen más información sobre cómo dar formato a una traducción o una lección nueva en Markdown:
-
-- [Introducción a Markdown](../es/lecciones/introduccion-a-markdown), un tutorial de _The Programming Historian_ escrito por Sarah Simpkin.
-- [GitHub Guide to Markdown]
-
-
Antes de continuar, por favor, asegúrate de que entiendes cómo utilizar la sintaxis Markdown para marcar el texto con encabezados, negrita, cursiva, enlaces, párrafos y listas.
-
-Para hacer esto más sencillo, hemos generado una plantilla que te pedimos que uses en todas las lecciones:
-
-```
- title: ["EL TÍTULO DE LA LECCIÓN"]
- collection: lessons
- layout: lesson
- slug: [DEJAR EN BLANCO]
- date: [DEJAR EN BLANCO]
- translation_date: [DEJAR EN BLANCO]
- authors:
- - [NOMBRE APELLIDO 1]
- - [NOMBRE APELLIDO 2, etc]
- reviewers:
- - [DEJAR EN BLANCO]
- editors:
- - [DEJAR EN BLANCO]
- translator:
- - [NOMBRE APELLIDO 1]
- translation-editor:
- - [DEJAR EN BLANCO]
- translation-reviewer:
- - [DEJAR EN BLANCO]
- original: [DEJAR EN BLANCO]
- review-ticket: [DEJAR EN BLANCO]
- difficulty: [DEJAR EN BLANCO]
- activity: [DEJAR EN BLANCO]
- topics: [DEJAR EN BLANCO]
- abstract: [DEJAR EN BLANCO]
- ---
-{% include toc.html %}
-
-# Contenidos
-
-# Encabezado de primer nivel
-
-[El contenido aquí. Por favor, escribe de manera formal, sostenible, y para una audiencia global.]
-
-## Encabezado de segundo nivel - con algunos ejemplos de formato
-
-### Formato de letra:
- *texto en cursiva*
- **texto en negrita**
- `funciones o nombres de arcivos` (por ejemplo, "for loop", o "misDatos.csv")
-
- ### Enlaces:
-[un enlace a *Programming Historian en español*](https://programminghistorian.org/es/)
-
-### Imágenes:
-
-
-
-
-
-
-
Leyenda o pie de imagen
-
-
-
-### Ejemplo de listado no ordenado
-
-* Frutas
- * Manzanas
- * Naranjas
- * Uvas
-* Lácteos
- * Leche
- * Queso
-
-### Ejemplo de listado ordenado
-
-1. Acabar tutorial
-2. Ir al supermercado
-3. Preparar la comida
-
-### Ejemplo de una tabla:
-
-| Encabezado 1 | Encabezado 2 | Encabezado 3 |
-| --------- | --------- | --------- |
-| Fila 1, columna 1 | Fila 1, columna 2 | Fila 1, columna 3|
-| Fila 2, columna 1 | Fila 2, columna 2 | Fila 2, columna 3|
-| Fila 3, columna 1 | Fila 3, columna 2 | Fila 3, columna 3|
-
-### Una nota a pie de página:
-
-Esto es un texto.[^1]
-Esto es más texto.[^2]
-
-# Notas
-[^1] Cita en formato Manual de Estilo Chicago
-[^2] Cita en formato Manual de Estilo Chicago
+
+Aceptamos tutoriales relevantes para las humanidades, dirigidos a cualquier nivel de aptitud técnica y experiencia, que se centren en un problema o proceso, que puedan ser sostenibles a largo plazo y que estén dirigidos a una audiencia global. El alcance y la longitud del tutorial han de corresponderse con la complejidad de la tarea que se enseña. Los tutoriales no deben exceder las 8.000 palabras (incluyendo el código) sin el permiso explícito del editor, el que se otorgará únicamente en circunstancias excepcionales. Esperamos que la mayoría de las lecciones tengan entre 4.000 y 6.000 palabras. Si resulta pertinente, puede que solicitemos dividir en varios tutoriales las lecciones más largas.
+
-```
+Si tienes una idea para una nueva lección, completa el [formulario de propuestas](/assets/forms/Lesson.Query.Form.txt) y envíalo a {% include managing-editor.html lang=page.lang %}.
-## Identifica tu archivo
+Para tener una idea de lo que publicamos, consulta nuestras [lecciones ya publicadas]({{site.baseurl}}/es/lecciones), lee nuestra [guía para revisores]({{site.baseurl}}/es/guia-para-revisores) o explora [las lecciones actualmente en desarrollo](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones). Animamos el envío de propuestas de lecciones sobre temas ya cubiertos o en desarrollo, siempre que la lección nueva haga una contribución propia.
-Identifica tu traduccion o lección nueva siguiendo estas instrucciones:
+A fin de que nuestras lecciones sean sostenibles a largo plazo, se sugiere proponer tutoriales que no dependan de un programa o de una interfaz específica que no haya demostrado ser estable en el tiempo. De lo contrario, los tutoriales necesitarían cambios con cada actualización. En aras de una mayor conservación, es mejor enseñar conceptos que a ‘hacer clic sobre un botón X’. Asimismo, se espera que los tutoriales no se centren en documentar cómo utilizar un determinado programa/aplicación/interfaz, sino que muestren cómo abordar un caso de estudio propio de las humanidades a través de esa(s) herramienta(s).
-- El nombre de archivo debe estar en minúscula y ser breve pero descriptivo. Este nombre de archivo se convertirá al final en el *[slug]* de la URL con que se publique en internet. Por ejemplo, la lección titulada "Introducción a Markdown" tiene el *slug* `introduccion-a-markdown` y la URL `https://programminghistorian.org/es/lecciones/introduccion-a-markdown`. Para ver más ejemplos, consulta el resto de lecciones publicadas.
-- Tu *slug* será referenciado más tarde de la siguiente manera: LECCION-SLUG.
-- Ten en cuenta la forma en que los lectores potenciales pueden encontrar tu lección en los buscadores. Un *slug* que se componga de palabras clave es una muy buena forma de recibir visitas.
-- No utilices espacios o guiones bajos `(_)` para separar palabras, utiliza el guion medio `(-)`.
-- La extensión de tu archivo debe ser `.md` (markdown).
+Tras la aprobación de tu propuesta, crearemos una página en el [sitio de envíos](https://github.com/programminghistorian/ph-submissions/issues) con el título provisional y los objetivos de la lección. Esto sirve para documentar el progreso realizado durante la escritura de la lección. Para asegurar la publicación oportuna, te pedimos que entregues tu texto al cabo de 90 días tras la aprobación. Durante este período de 90 días, tu punto de contacto será la jefe de redacción o el editor o editora que se haya asignado para acompañarte durante el proceso.
-### Formato de notas a pie de página
-Pedimos a los autores y traductores que citen de acuerdo al [Manual de Estilo Chicago](https://es.wikipedia.org/wiki/Manual_de_estilo_de_Chicago).
+## Paso 2: Escribir y formatear el tutorial
+Esta guía de estilo define un conjunto de normas para ser utilizadas al crear lecciones en español para *Programming Historian*. Al seguir estos lineamientos nos ayudas a asegurar que el contenido sea consistente y accesible.
-### Utiliza encabezados en cada sección
-Queremos que nuestras lecciones sean fáciles de leer mediante el uso consistente de encabezados de sección en todas las lecciones. A medida que escribes o traduces una lección, los niveles conformados por las secciones te ayudarán a visualizar la estructura de la lección. Por favor, evita secciones largas sin encabezados (son necesarios para facilitar la lectura).
+La guía contempla tres secciones, que deben ser leídas antes y después de la escritura:
-Los encabezados no se generan mediante **negrita** o *cursiva* sino con la anotación de Markdown oportuna. A menos que la lección sea muy breve, tu estructura precisará de tres niveles como mínimo.
+* A. Estilo y audiencia
+* B. Pautas específicas de escritura
+* C. Guía de formato
-Aunque hay varias maneras de crear encabezados de secciones en Markdown, pedimos el uso de la notación `#` (numeral o almohadilla). Los encabezados de nivel superior se indican con un símbolo `#`; el segundo nivel con dos `##`; etc.
+## A. Estilo y audiencia
+Esta primera sección se ocupa de cuestiones de estilo generales que te ayudarán a tomar decisiones que satisfagan las necesidades de nuestra audiencia y editores. Incluimos información básica sobre el estilo y el tono, el acceso abierto y los valores del código abierto, información sobre la escritura para una audiencia global, la escritura sostenible y la toma de decisiones inteligentes sobre los datos utilizados en las lecciones. Lee esta sección cuando planifiques tu lección y vuelve a leerla antes de enviarla para asegurarte de que el tutorial cumple con estos requisitos.
-### Alertas
-Si quieres añadir información sobre algo que no es esencial para la lección pero que crees que puede ser importante (o que corresponde a ciertos lectores), puedes marcarlo usando el [estilo de alertado](https://v4-alpha.getbootstrap.com/components/alerts/) (tomado de Bootstrap).
+### Lenguaje y estilo
+* Los tutoriales no deben exceder las 8.000 palabras (incluyendo el código).
+* Mantén un tono formal, pero accesible.
+* Habla con tu lector en segunda persona singular (tú).
+* Procura escribir de un modo comprensible y adecuado para hablantes de español de distintas zonas geográficas.
+* Refiérete a tu escrito como "tutorial" o "lección", no como "artículo".
+
+### Código abierto, acceso abierto
+*Programming Historian* está comprometido con los valores del código abierto. Todas las lecciones deben usar lenguajes de programación y software de código abierto siempre que sea posible. Esta política tiene por objeto reducir al mínimo los costos para todas las partes y permitir el mayor nivel de participación posible.
+
+Una vez aprobada tu lección, aceptas que se publique bajo licencia Creative Commons "[CC-BY](https://creativecommons.org/licenses/by/4.0/deed.es)".
+
+### Escribe para una audiencia global
+*Programming Historian* es leído por personas que viven en todo el mundo. Es por ello que debes tomar medidas para que tu lección sea accesible para el mayor número de personas posible. Las siguientes directrices te ayudarán a enfrentar una audiencia global:
+
+* Escribe para alguien que no vive en tu país o que no comparte tus creencias.
+
+* **Términos técnicos:** siempre deben estar vinculados a [Wikipedia](https://es.wikipedia.org/), a un diccionario fiable o a un sitio web sostenible, en primera instancia. Un término técnico es cualquier palabra que una persona en la calle puede no conocer o entender. Idealmente, estas fuentes deben estar en español.
+* **Referencias culturales**: las menciones a personas, organizaciones o detalles históricos deben acompañarse siempre con información contextual. No hay que suponer ningún conocimiento previo, incluso de referencias culturales ampliamente conocidas (por ejemplo, [The Beatles](https://es.wikipedia.org/wiki/The_Beatles)). Utiliza términos genéricos en lugar de marcas comerciales (pañuelo desechable en lugar de Kleenex, por ejemplo). Los enlaces a [Wikipedia](https://es.wikipedia.org/) deben ser usados tanto como sea necesario. Ten en cuenta también que algunos eventos históricos a veces reciben diferentes nombres según el país.
+* **Modismos**: Evita bromas, juegos de palabras, expresiones idiomáticas, sarcasmo, emojis, jerga, términos exclusivos de tu variante lingüística o vocabulario más difícil de lo necesario.
+* **Geografía**: cuando hagas referencia a lugares, sé específico. ¿"Noroeste" significa Brasil? ¿India? ¿África? Escribe siempre el nombre completo del área la primera vez que la menciones.
+* **Multilingüismo**: al elegir los métodos o instrumentos, ten en cuenta a lectores y lectoras multilingües, especialmente en el caso de los métodos de análisis textual, que pueden no ser compatibles con otros conjuntos de caracteres o que solo pueden proporcionar resultados sólidos cuando se utilizan en textos en inglés. Cuando sea posible, elige enfoques que tengan documentación multilingüe o proporciona referencias multilingües para su lectura posterior. Esto ayudará a nuestros traductores en el futuro.
+* **Lenguaje racial y étnico**: usa la terminología racial cuidadosamente y con especificidad. Los términos históricos que ya no se utilizan deben usarse solo en su contexto histórico y solo cuando sea necesario. Usa los términos raciales como adjetivos y no como sustantivos: personas blancas en lugar de "blancos", una mujer asiática en lugar de "una asiática". Ten en cuenta que los términos pueden entenderse de manera diferente en distintos países y que lo que has aprendido como un uso correcto o sensible puede ser culturalmente específico de tu país (por ejemplo, no todas las personas de ascendencia africana son "afroamericanos". Algunos de ellos son africanos, o negros británicos, o caribeños, etc.). Asimismo, las personas del Reino Unido entenderán el término "asiático" (India, Pakistán, Bangladesh) de manera diferente a las de América del Norte (por ejemplo, China, Japón, Vietnam, Tailandia).
+* **Representaciones visuales**: elije las fuentes primarias, imágenes, figuras y capturas de pantalla, teniendo en cuenta una audiencia global.
+
+### Escritura sostenible
+*Programming Historian* publica lecciones pensando en el largo plazo. Por favor, sigue estas directrices sobre sostenibilidad cuando escribas:
+
+ * **Tan general como sea posible, pero no más**: concéntrate en las metodologías y generalidades, no en los programas informáticos/interfaces específicos (por ejemplo, de ser posible, evita decir a los usuarios que "hagan clic en el botón X", que podría ser diferente en versiones futuras).
+ * **Reducir la dependencia de elementos insostenibles**: utiliza capturas de pantalla con moderación y con un propósito claro. Las interfaces cambian con frecuencia y los futuros lectores podrían confundirse si su versión no se ve exactamente igual. Elije los enlaces externos teniendo en cuenta el futuro. ¿Cambia a menudo el sitio al que se enlaza? ¿Existirá dentro de diez años?
+ * **Especifica las versiones si son importantes**: sé claro acerca de los detalles específicos de las versiones utilizadas en caso de que sean necesarios para poder seguir la lección. Por ejemplo, ¿se necesita Python v.3 o cualquier versión estará bien? ¿Funciona con cualquier versión de Java? ¿Habrá problemas si se usa una versión de R anterior a 3.5?
+ * **Refiérete a la documentación**: haz referencia a documentación fiable cuando sea posible. Proporciona una guía general sobre cómo encontrar la documentación en caso de que sea probable que haya nuevas versiones en el futuro.
+ * **Copias de datos**: todos los datos utilizados en las lecciones deben ser publicados en los servidores de *Programming Historian* junto con tu lección. Asegúrete de tener el derecho legal de publicar una copia de cualquier dato utilizado. Los archivos de datos deben utilizar formatos abiertos, no dependientes de un software particular.
+
+Consulta nuestra [política de retirada de lecciones]({{site.baseurl}}/es/politica-retirada-lecciones) para información sobre cómo el equipo editorial maneja las lecciones que se han vuelto obsoletas.
+
+## B. Pautas específicas de escritura
+En esta segunda sección se abordan cuestiones más específicas del estilo de escritura, como qué palabras utilizar, cómo usar la puntuación o qué formato utilizar para fechas y números. Lee esta sección antes y después de escribir tu borrador.
+
+### Fechas y hora
+ * Para siglos, utiliza números romanos. Evita frases centradas en lo nacional, como "el largo siglo XVIII", que tienen un significado específico para los especialistas británicos del siglo XVIII, pero para nadie más.
+ * Para décadas escribe "los años cincuenta" o "los cincuenta" (no "los años 50's" o "la década de los 50s").
+ * Comprime las secuencias de fecha así: 1816-17, 1856-9, 1854-64.
+ * Para fechas escritas en forma numérica utiliza el formato AAAA-MM-DD, conforme al estándar ISO 8601:2004. Esto evita la ambigüedad.
+ * Utiliza a. C. (‘antes de Cristo’) o d. C. (‘después de Cristo’): 211 a. C., 123 d. C.
+ * Para horas: 1 a.m., 6:30 p.m. Es preferible diez de la noche o 10 p.m. antes que 10 de la noche.
+
+### Números
+ * Se escriben con palabras los números:
+ * que pueden expresarse en una sola palabra (del cero al veintinueve, las decenas como treinta, cuarenta, etc.) y las centenas (cien, doscientos, etc.)
+ * los números redondos que pueden expresarse en dos palabras (quinientos mil, etc)
+ * los números que se expresan en dos palabras unidas por una conjunción y hasta noventa y nueve.
+ En caso de que tengas dos referencias numéricas que supongan distintos formatos, elige uno solo para ser consistente (cinco manzanas y ciento diez naranjas; 5 manzanas y 110 naranjas).
+ * Al escribir números de más de cuatro cifras sepáralas en grupos de tres dígitos desde la derecha dejando un espacio (no puntos ni comas). Por ejemplo, 32 904, no 32904, 32.904 o 32.904. Excepciones: años, páginas, versos, portales de vías urbanas, apartados de correos, números de artículos legales, decretos o leyes.
+ * Para separar la parte entera de la decimal debe usarse la coma (1,5)
+ * Usa numerales para hacer referencia a versiones (versión 5 o v.5).
+ * Al referirte a porcentajes, utiliza el símbolo % con numerales y la expresión _por ciento_ cuando escribes el cifra con palabras (por ejemplo, _5%_ o _cinco por ciento_. No _5 porciento_ o _cinco %_). En porcentajes inferiores a 1, agrega un cero antes de la coma decimal (0,05%).
+ * Utiliza el [formato LaTeX para fórmulas matemáticas](https://davidhamann.de/2017/06/12/latex-cheat-sheet/).
+ * Para unidades de medida utiliza el sistema métrico.
+
+### Encabezados
+Los encabezados no deben contener código en línea o un formato de estilo como negrita, cursiva o de código.
+Los encabezados siempre deben preceder inmediatamente al texto del cuerpo. No pongas después de un encabezado una advertencia u otro encabezamiento sin un texto introductorio o descriptivo.
+
+
+### Listas
+Típicamente, usamos listas numeradas y listas con viñetas. Los elementos de la lista comienzan con mayúscula. Los elementos de la lista deben ser tratados como elementos separados y no deben ser encadenados con puntuación o conjunciones.
+
+Sin estilo apropiado:
+
+* Acá hay un ítem y
+* acá hay otro ítem; y
+* acá hay un ítem final.
+
+Con estilo:
+
+* Acá hay un ítem
+* Acá hay otro ítem
+* Acá está el último ítem
+
+### Puntuación
+ * **Abreviaturas, acrónimos y siglas**: escribe la palabra completa la primera vez que la utilizas, por ejemplo, «Humanidades Digitales (HD)». Las siglas son invariables cuando se enunician en plural («las ONG») y adoptan el género de la palabra que constituye el núcleo de la expresión abreviada, que normalmente ocupa el primer lugar en la denominación: el FMI, por el «Fondo» Monetario Internacional; la OEA, por la «Organización» de Estados Americanos. Las siglas se escriben sin puntos o espacios en blanco como separación: RAE, OEA, etc. (no R.A.E. u O E A). Normalmente se escriben en mayúscula todas las letras que componen una sigla (OCDE, APA, ISO) y, en ese caso, no llevan nunca tilde, incluso en casos en que la norma ortográfica indicaría su uso (como en CIA).
+ * **Paréntesis**: se usa para insertar en un enunciado una información complementaria o aclaratoria, ej: El dijo: «Cuando lo acaben (el túnel) revolucionará la forma de viajar» or «Ella dijo goodbye (adios)». Ubica el punto fuera del paréntesis de cierre si lo que está dentro de él no es una oración completa (como este caso). (Una oración independiente, en cambio, lleva el punto final antes del paréntesis de cierre.)
+ * **Dos puntos**: se utilizan para introducir listas, ejemplificaciones, aclaraciones, citas textuales, etc., como en estos ejemplos:
+ * El comité recomienda: ampliar las horas de licencia hasta la medianoche; permitir a los niños en los locales con licencia; relajar los controles de planificación en los nuevos establecimientos públicos.
+ * Después de dos puntos va minúscula: así es como lo hacemos.
+ * **Raya**: para encerrar aclaraciones o incisos.
+ * **Guión**: se usa como signo de unión entre palabras y como signo de división de palabras a final de línea.
+ * **Puntos suspensivos**: van pegados a la palabra que los precede y separados de la que los sigue. Cuando se utilizan para condensar una cita directa, van entre paréntesis o corchetes.
+ * **Signos de exclamación**: se utilizan al comienzo y al final de la exclamación.
+ * **Punto**: se escribe punto después de las abreviaturas, pero no de las siglas o acrónimos.
+ * **Comillas angulares**: en los textos impresos, se recomienda utilizar en primera instancia las comillas angulares « », (ejemplo: «Antonio me dijo: “Vaya ‘cacharro’ que se ha comprado Julián”»). Se reservan los otros tipos para cuando se debe entrecomiilar un texto ya entrecomillado.
+
+### Mayúsculas
+La pauta es usarlas con moderación en la prosa corriente. Reglas específicas:
+
+* **Títulos**: los encabezados y títulos de libros llevan mayúscula en la primera letra del título: »Preparando los datos para el análisis»; *El orgullo y la pasión*.
+* **Siempre con mayúscula inicial**:
+ * **Nombre propios**: William J. Turkel – a menos que la persona elija deletrear su nombre de otra manera (por ejemplo "bell hooks").
+ * **Organizaciones, organismos, entidades, partidos políticos, etc**: Museo de Arte Moderno, Casa de Cervantes, Biblioteca Nacional, Agencia Nacional de Tierras, Naciones Unidades. Las palabras de función dentro del nombre no llevan mayúsculas en estos casos.
+ * **Días festivos y festivales**: Diwali, Hanukkah, Eid-Ul-Adha, Día de los Muertos.
+* **A veces o solo parcialmente en mayúsculas**:
+ * **Lugares**: capitales de países, regiones, zonas reconocibles (por ejemplo, el Oriente Medio, Senegal). Minúsculas para los puntos cardinales, a excepción de cuando son utilizados como parte del nombre de un lugar (para llegar al Polo Norte, dirigirse al norte). Otros ejemplos son: el noreste de Kenya, el sur del Brasil, el oeste, el oeste del Canadá, el extremo oriental, el Asia sudoriental, América Central, América Latina.
+ * **Eventos históricos**: mayúscula inicial, como en Primera Guerra Mundial, Segunda Guerra Mundial; Guerra de Crimea/Boer/Vietnam/del Golfo; Guerra de los Cien Años.
+ * **Religión**: minúscula, como en anglicano/a, bautista, budista, católico/a, cristiano/a, hindú, metodista, musulmán/a, protestante, católico/a romano/a, sikh, y también para evangélicos/as, carismáticos/as, ateos/as.
+ * **Disciplinas**: Se escriben con minúscula, salvo cuando hacen referencia a nombres de asignaturas, carreras, departamentos, etc.
+ * **Libros sagrados (selección)**:
+ * **Biblia**: mayúscula si se refiere al Antiguo o al Nuevo testamento.
+ * **Budismo**: sutras (sermones) y abhidhamma (análisis e interpretación). Para el budismo tibetano tambien hay libros tántricos y Libro tibetano de los muertos.
+ * **Hinduismo**: los Śruti: Vedas, Samhitas, Brahmanas, Aranyakas, Upanishads; los Vedāngas, épica Hindú, sutras, shastras, textos filosóficos, los Puranas, literatura kāvya, los Bhasyas, muchos nibandhas.
+ * **Judaismo**: el Tanakh (Torá, Nevi'im, Ketuvim), el Talmud (Mishná, Guemará)
+ * **Corán**: textos que incluyen los hadiz, el Tawrat (Torá), Zabur (posiblemente salmos), Injil (1.2 billones).
+ * **Sikh**: Adi Granth (comúnmente llamado el Sri Guru Granth Sahib Ji), el Dasam Granth, los Varan Bhai Gurdas, los textos del Bhai Nand Lal.
+ * **Trabajos**: en minúscula – presidente Macron, Emmanuel Macron, presidente de Francia. El ministro de Hacienda. El Papa se escribe con mayúscula y la reina en minúscula.
+ * **Organizaciones e instituciones**: el gobierno (en minúscula en toda referencia), el gabinete (minúscula en toda referencia), la Iglesia de Jesucristo de los Santos de los Últimos Días ("la iglesia"), Ministerio de Educación ("el ministerio"), Universidad Católica ("la universidad"), el Tribunal de Apelación ("tribunal de apelación" o "el tribunal").
+ * **Universidades e institutos**: mayúsculas para la institución y para departamentos ("Universidad Autónoma de México", "Departamento de Historia").
+* **Siempre en minúscula**:
+ * **Días de la semana y meses**: martes, diciembre.
+ * **Estaciones**: primavera, verano, otoño, invierno.
+ * **Tipos de cambio**: peso, sol, euro, franco, marco, dong, etc.
+
+
+### Casos especiales y otros elementos a tener en cuenta
+* La palabra _solo_ y los demostrativos no se tildan.
+* Las voces latinas terminadas en _t_ o _m_ forman el plural en español agregando una ese. Se desaconseja usar, como sucede por influjo del inglés, el plural latino: el plural de _currículum_ es _currículums_, no _currícula_). En la misma línea, la palabra _corpus_ es invariable en plural, por lo que no debe utilizarse _corpora_ como plural.
+* La expresión correcta es _en relación con_ o _con relación a_, no _en relación a_.
+* La conjunción es _sobre la base de_ o _con base en_, no _en base a_.
+
+
+### Referencias
+* En la mayoría de los casos, lo más apropiado es incluir un enlace más que una nota final.
+* Asegúrate de que las frases vinculadas tengan un significado semántico. No enlaces términos que son significativos solo para usuarios videntes como "haz clic aquí".
+* Toda la literatura tradicional y académica debe incluirse como nota al final, en lugar de como enlace.
+* Si estás escribiendo un tutorial de "análisis", debes referirte a la literatura académica publicada.
+* Los superíndices de las notas finales deben ir dentro de la puntuación final: así². No afuera: así.²
+* Utiliza el sistema de "Notas y Bibliografía" que se encuentra en el [Manual Chicago 17a edición](https://uc3m.libguides.com/guias_tematicas/citas_bibliograficas/chicago) para las notas al final.
+* Cuando se mencione por primera vez una obra publicada, incluye el nombre del autor (incluyendo el primer nombre). Por ejemplo, «Puedes encontrar más información en *The Elements of Typographic Style* de Robert Bringhurst» o «Para más información, consulta *The Elements of Typographic Style* de Robert Bringhurt». En las referencias posteriores, usa solo el título del libro. Los nombres de los autores pueden ser acortados a apellidos solo a partir de su segunda mención.
+* Las notas finales no pueden contener solo una URL.
+ * (Correcto): Grove, John. "Calhoun and Conservative Reform." *American Political Thought* 4, no. 2 (2015): 203–27. https://doi.org/10.1086/680389.
+ * (Incorrecto): https://doi.org/10.1086/680389.
+
+
+
+### Lenguaje inclusivo y no discriminatorio
+En Programming Historian nos comprometemos a publicar tutoriales que no reproduzcan lenguaje sexista y discriminador. Te pedimos que tengas en cuenta las siguientes recomendaciones:
+
+* Al referirte a personas o grupos de personas que presentan algún tipo de discapacidad, evita los binarismos normal/anormal, capaz/incapaz y términos como "capacidades diferentes" e "incapacidad".
+* No te refieras a pueblos y comunidades indígenas con términos que son considerados despectivos o que no son los que sus miembros prefieren utilizar. Por ejemplo, prefiere inuit frente a "esquimal", o mapuche frente a "araucano".
+* Cuando sea posible, sustituye el masculino genérico por un sustantivo que denomine sin una carga de género al colectivo de personas, a la profesión, a la institución o al lugar.
+Por ejemplo, "la audiencia", en vez de "los lectores"; "el parlamento" en vez de " los parlamentarios".
+* Haz cambios en la redacción que eviten tener que utilizar un sustantivo o adjetivo con flexión de género. Por ejemplo, "este punto ha sido muy importante para los historiadores" podría reescribirse como "este punto ha sido muy importante en una disciplina como la historia".
+* Utiliza la forma femenina cuando el referente es una mujer: la presidenta, no la presidente; la jueza, no la juez.
+* Utiliza la palabra persona o personal más un adjetivo para referirte a un grupo y evitar así la forma masculina. Por ejemplo, en ciertos contextos "los docentes" puede remplazarse por "el personal docente".
+* También es posible desdoblar los sustantivos y adjetivos en en femenino y masculino (por ejemplo, "los autores y autoras"). Sin embargo, recomendamos utilizar este recurso con moderación, ya que en ocasiones su uso excesivo hace la lectura de un texto menos fluida.
+
+
+## C. Guía de formato
+Esta última sección abarca cuestiones de formato para el envío de tu lección. Lee esta sección antes y después de escribir tu borrador. Si te equivocas en alguno de estos elementos, podrás corregirlo cuando publiquemos un avance en línea de tu lección al comienzo del proceso de revisión de pares.
+
+### Escribe en Markdown
+Todas las lecciones deben ser escritas en [Markdown](https://es.wikipedia.org/wiki/Markdown). Se ha proporcionado una plantilla para escribir las lecciones.
+
+* [Descarga la plantilla para lecciones en español (.md)]({{site.baseurl}}/es/plantilla-leccion.md).
+
+Markdown es un lenguaje de marcado que se crea mejor con un editor de texto. MS Word y Open Office NO son editores de texto y deben ser evitados. Recomendamos [Atom](https://atom.io/), [TextWrangler](https://www.barebones.com/products/textwrangler/), [TextEdit](https://en.wikipedia.org/wiki/TextEdit), [MacDown](https://macdown.uranusjr.com/), [Notepad++](https://notepad-plus-plus.org/download) o [Sublime Text](https://www.sublimetext.com/).
+Para una introducción sencilla a Markdown puedes ver la lección [Introducción a Markdown]({{site.baseurl}}/es/lecciones/introduccion-a-markdown) o la referencia concisa [GitHub Guide to Markdown](https://help.github.com/es/github/writing-on-github/basic-writing-and-formatting-syntax).
+
+Tu lección debe ser guardada en formato .md. El nombre del archivo de tu lección se convierte en parte de la URL de la lección, por lo tanto, debe ser nombrado de acuerdo a las siguientes reglas:
+
+ * Un nombre corto, en minúsculas, descriptivo y que dé una clara indicación del contenido de la lección (por ejemplo, introduccion-a-markdown.md).
+ * No utilices espacios ni guiones bajos en el nombre del archivo; utiliza guiones.
+ * Utiliza un nombre de archivo rico en palabras clave que incluyan las tecnologías o métodos usados en la lección (por ejemplo, Python o Análisis de Sentimientos).
+
+### Negrita, cursiva y subrayado
+Para asegurar la consistencia de las lecciones, sigue las siguientes directrices de formato de texto:
+
+#### Negrita
+ * La negrita no se usa excepto en circunstancias excepcionales.
+ * La negrita se formatea utilizando **\*\*doble asterisco\*\***.
+
+#### Cursiva
+* Usa la cursiva para los títulos de libros, películas, programas de TV, pinturas, canciones, álbumes y sitios web.
+* Nunca uses la cursiva para nombres de empresas (el sitio web *Facebook* es propiedad de Facebook).
+* No uses la cursiva en los títulos de secciones, incluso si te estás refiriendo título de un libro.
+* La cursiva se formatea utilizando *\*un asterisco\**.
+
+#### Subrayado
+ * No se utiliza.
+
+### Alertas y advertencias
+Si quieres incluir un aparte o una advertencia, puedes utilizar el siguiente bloque de código:
-Para ello, necesitas utilizar HTML, tal que
```
- Asegurate de seguir las instrucciones con cuidado!
+¡Asegúrate se seguir cuidadosamente las instrucciones!
```
-Esto se verá así en la lección:
-
¡Asegurate de seguir las instrucciones con cuidado!
-
-
-### Reglas especiales de estilo
-Como toda revista académica, *The Programming Historian en español* también tiene su estilo propio, que esperamos que los autores y traductores sigan de manera consistente a lo largo de las lecciones. A diferencia de la mayoría de revistas, sin embargo, no seguir con estas normas de estilo no solo disminuye la consistencia estilística sino que también afecta a la visualización del archivo entero.
-#### Figuras
-Sin importar su longitud o nivel de dificultad, todas las lecciones se benefician de tener imágenes, sobre todo capturas de pantalla (o capturas parciales) que ilustran lo que los lectores deberían ver mientras realizan el tutorial. No sólo hacen el tutorial más fácil de ojear; las figuras ayudan al lector a ver que está haciendo lo correcto. Y por su puesto, las imágenes pueden ayudar a reducir las descripciones en tu texto.
+### Figuras e imágenes
+Las imágenes pueden ayudar a tu audiencia a entender los pasos de la lección, pero no deben ser usadas como decoración. Si deseas utilizar imágenes en tu lección, etiquétalas secuencialmente siguiendo el patrón: `nombre-leccion1.jpg`, `nombre.leccion2.jpg`, etc. Refiérete a ellas en el texto como "Figura 1", "Figura 2" y así sucesivamente. Todas las figuras deben venir con una leyenda concisa y notas finales cuando sea apropiado. Debes tener el derecho legal para publicar cualquier imagen que incluyas en tu lección.
-#### Crea una carpeta
-Primero, crea una carpeta en la que guardarás las imágenes. El nombre de la carpeta tiene que ser el mismo que el ```SLUG-DE-LA-LECCION``` que hayas escogido para el nombre del archivo de tu lección. El editor asignado a tu lección te puede ayudar a cargar las imágenes al repositorio ```ph-submissions``` cuando subas tu lección.
+Utiliza formatos de archivos amigables para la web, como .png o .jpg, y reduce las imágenes grandes a un máximo de 840 px en el lado más largo. Esto es importante para lectores en países con velocidades de Internet más lentas.
-#### Utiliza nombres de archivo legibles
-Hay dos formas en las que puedes dar nombre a tus archivos. Una opción es usar nombres significativos que indiquen claramente lo que contiene la imagen. De forma alternativa, puedes usar una secuencia para sus nombres, usando el mismo *slug* con guiones de la lección (o una forma abreviada) seguido por un número. (Por ejemplo, ```recuento-frecuencias-1.png```, ```recuento-frecuencias-2.png```, y así).
+Las imágenes deben guardarse en una carpeta con el mismo nombre que el archivo .md de la lección.
-#### Utiliza formatos y tamaños estándar
-Asegúrate de que las imágenes están en un formato sostenible como PNG o JPEG y de que su tamaño es apropiado (tanto en píxeles como en bytes).
-
-#### Cómo incluir las imágenes
-Cuando quieras insertar una imagen, utiliza la siguiente línea de código en el cuerpo de tu lección:
+Para insertar una imagen en tu texto, utiliza el siguiente formato:
{% raw %}
-```markdown
-{% include figure.html filename="NOMBRE-DE-IMAGEN" caption="LEYENDA O PIE DE IMAGEN CON \"CARACTER DE ESCAPE\" PARA LAS COMILLAS/CITAS" %}
+``` markdown
+{% include figure.html filename="NOMBRE-ARCHIVO-IMAGEN" caption="PIE DE FOTO UTILIZANDO \"ESCAPED\" QUOTES" %}
```
{% endraw %}
-
Tienes que modificar ```NOMBRE-DE-IMAGEN``` y ```Leyenda o pie de imagen``` según tu imagen y la lección. No olvides que las comillas (") dentro de los títulos de las figuras deben ir precedidas por el caracter de escape o barra invertida (\), como en el ejemplo anterior. Nota que cuando se añaden etiquetas de figura de esta manera, la imagen no se mostrará en la vista previa de Github ni en la vista previa de otros programas en que estés usando Markdown.
+Ten en cuenta que las comillas internas en el pie de foto deben escaparse con una barra invertida, como en el ejemplo anterior. Es posible que las imágenes no aparezcan en las vistas previas de la lección, pero tu editor/a se asegurará de que se reproduzcan correctamente cuando esta se publique.
-### Bloques de código
-Si necesitas incluir código en tu lección, o mostrar el resultado de un programa, utiliza el llamado [bloque de código destacado]. En una nueva línea, utiliza tres tildes graves para abrir un bloque, seguido del lenguaje de tu código (por ejemplo, ```python``` o ```html```). Luego copia tu código y cuando termines, cierra el bloque con tres tildes graves más. El marcado se procesara en el resultado final y se verá así:
-```
-print 'hola mundo'
-```
+### Ejemplos de código
+Las líneas de código deben tener un formato que las distinga claramente de la prosa:
-### Escribe de manera sostenible
-En *The Programming Historian* queremos que las lecciones puedan utilizarse a largo plazo. Por este motivo, recomendamos consultar nuestra [poltica de retirada de lecciones]({{site.baseurl}}/es/politica-retirada-lecciones), en donde describimos el procedimiento llevado a cabo cuando un tutorial se vuelve obsoleto. Con el propsito de incrementar la sostenibilidad de las lecciones, pedimos a los autores de originales que se ajusten a una serie de recomendaciones durante el proceso de escritura:
+ * Las líneas de código deben tener un máximo de 80 caracteres
+ * Los bloques de código de varias líneas deben estar encerrados en tres \`\`\`comillas invertidas\`\`\`
+ * El código dentro del texto (raramente usado) puede ser encerrado en una sola \`comilla invertida\`
-- En lugar de tratar cuestiones específicas sobre el funcionamiento de un programa, las lecciones deberían centrarse en la metodología y los aspectos generales de las herramientas.
-- Si la lección puede puede aprovechar la documentación existente del programa, recomendamos dirigir a los lectores a esta documentación en lugar de repetirla en la lección. Asimismo, en lugar de enlazar directamente a los recursos de un programa comercial (que a menudo cambia), es mejor proporcionar una orientación general sobre cómo encontrar la documentación.
-- Recomendamos un uso limitado de imágenes específicas de la versión del programa utilizado, a menos que sean estrictamente necesarias para seguir con la lección.
-- Revisa los enlaces externos para asegurarte de que funcionan y están actualizados.
-- Las fuentes y conjuntos de datos necesarios para llevar a cabo una lección deben hospedarse en nuestra web.
-### Escribir para una audiencia global
+```
+El bloque de código se verá así
+```
+` y así` el código dentro del texto.
+
-Los lectores de *Programming Historian* viven por todo el mundo y, como tal, trabajan en un amplio rango de contextos culturales. Para poder alcanzar a dicha audiencia global, hemos estado publicando en más de un idioma desde 2017 y nuestro objetivo es traducir todos los tutoriales. **Aunque reconocemos que no todos los métodos o herramientas son totalmente accesibles a nivel internacional**, los autores pueden y deben tomar medidas para escribir sus lecciones de manera que sean accessibles al mayor número de personas posible. **Por favor, considera lo siguiente al escribir tu tutorial**:
+Sigue las mejores prácticas para escribir tu código:
-* Al elegir métodos o herramientas, toma decisiones con una audiencia multilingüe en mente. Esto es particularmente importante cuando se trabaja con métodos de análisis textual, o cuando los usuarios quieran tener soporte para diferentes codificación de caracteres de forma razonable (por ejemplo, caracteres acentuados, no latinos, etc.).
-* Al elegir fuentes primarias e imágenes, al crear figuras o al hacer capturas de pantalla, considera cómo se presentarán a una audiencia global.
-* Al escribir, evita usar chistes, referencias culturales, juegos de palabras, expresiones idiomáticas, sarcasmo, emojis o un lenguaje innecesariamente complicado. Las menciones a personas, a organizaciones o a eventos históricos siempre deben ir acompañadas de información contextual. Te puede resultar útil pensar que tu audiencia no vive en tu país o que no habla tu mismo idioma.
-* En los ejemplos de código o metadatos, utiliza formatos estándar internacionalmente reconocidos para fechas y horas ([ISO 8601: 2004](https://www.iso.org/standard/40874.html)). En el texto, ten en cuenta las diferencias culturales relacionadas con la presentación de fechas y horas que puedan causar confusión.
-* Cuando sea posible escoge métodos y herramientas que tengan documentación multilingüe. Si esto no es posible, trata de agregar algunas referencias multilingües al final del tutorial.
+* **Nombres de variables y funciones**: los nombres de variables deben ser sustantivos (por ejemplo, "nombre_coleccion") y los nombres de funciones verbos (por ejemplo, "crear_archivo"). Elije nombres concisos y significativos. Puedes usar el formato [snake_case](https://en.wikipedia.org/wiki/Snake_case) o [camelCase](https://en.wikipedia.org/wiki/Camel_case); lo importante es que seas consistente a lo largo de la sección.
+* **Comandos a editar**: cuando hagas referencia a texto que quieres que el usuario remplace con su propia información, utiliza MAYÚSCULAS rodeadas de ` tildes graves ` (por ejemplo, \`NOMBRE USUARIO ACÁ\`).
+* **Nombres de archivos**: los nombres de archivos que solicites crear en tu lección deben estar rodeados de tildes graves cuando se mencionan en el texto y deben incluir la extensión del archivo. Elije nombres concisos y significativos. Puedes usar [snake_case](https://en.wikipedia.org/wiki/Snake_case) o [camelCase](https://en.wikipedia.org/wiki/Camel_case); lo importante es que seas consistente (por ejemplos, `datos.txt`, `datosLimpios.py`, `grafico_autores.png` etc).
+* **Palabras reservadas**: los términos que son parte de un lenguaje de programación deben estar formateados como `código` usando tildes graves cuando los menciones en el texto. A continuación encontrarás una lista de nombres reservados de algunos lenguajes de programación comunes:
-Contacta con tu editor si necesitas orientación sobre alguno de estos asuntos. Es posible que no traduzcamos tu tutorial si no cumple con estas pautas, pero aún así lo consideraremos para su publicación monolingüe.
+#### JavaScript:
-
+`abstract`, `arguments`, `await`, `Boolean`, `break`, `byte`, `case`, `catch`, `char`, `class`, `const`, `continue`, `debugger`, `default`, `delete`, `do`, `double`, `else`, `enum`, `eval`, `export`, `extends`, `false`, `final`, `finally`, `float`, `for`, `function`, `goto`, `if`, `implements`, `import`, `in`, `instanceof`, `int`, `interface`, `let`, `long`, `native`, `new`, `null`, `package`, `private`, `protected`, `public`, `return`, `short`, `static`, `super`, `switch`, `synchronized`, `this`, `throw`, `throws`, `transient`, `true`, `try`, `typeof`, `var`, `void`, `volatile`, `while`, `with`, `yield`.
-# Enviar una traducción o una lección nueva
-Una vez tu archivo ha sido preparado de acuerdo con las especificaciones detalladas, ¡ya puedes enviárnoslo!
+#### Python 3:
+`and`, `as`, `assert`, `break`, `class`, `continue`, `def`, `del`, `elif`, `else`, `except`, `False`, `finally`, `for`, `from`, `global`, `if`, `import`, `in`, `is`, `lambda`, `nonlocal`, `None`, `not`, `or`, `pass`, `raise`, `return`, `True`, `try`, `while`, `with`, `yield`.
-Tenemos una página del proyecto [Programming Historian](https://github.com/programminghistorian) en GitHub, donde mantemos dos repositorios (es decir, un sitio en donde almacenar archivos y carpetas). Por un lado, tenemos el repositorio [jekyll](https://github.com/programminghistorian/jekyll), que contiene los archivos a los que se accede a través del navegador [web](/es). Por el otro, tenemos el repositorio llamado [ph-submissions].
+#### R:
+`break`, `else`, `for`, `FALSE`, `function`, `if`, `in`, `Inf`, `NA`, `NA_character_`, `NA_complex_`, `NA_integer_`, `NA_real_`, `NaN`, `next`, `NULL`, `repeat`, `TRUE`, `while`, `...` y `..1`, `..2`, etc.
-Los autores y traductores pueden enviarnos las lecciones de manera directa, es decir, añadiendo los archivos al repositorio [ph-submissions]. Gracias a las características de GitHub, puedes llevar a cabo esto arrastrando y soltando los archivos. Si colaboras con nosotros por primera vez, estas instrucciones pueden ser útiles:
-1. Crea una cuenta gratuita en GitHub [aquí](https://github.com/join). Solo se necesitan 30 segundos.
-2. Contacta con tu editor a través de tu cuenta de GitHub para proporcionarle tu nombre de usuario y el nombre de la lección traducida o escrita por ti tal y como está en el *slug*; ¡asegúrate de haber seguido las reglas descritas más arriba! A continuación, el editor te añadirá como **colaborador** en el repositorio [ph-submissions]. Una vez tengas acceso como colaborador, podrás hacer cambios de manera en los archivos (adiciones, edición, eliminación, etc.). El editor también creará una carpeta con el mismo nombre de tu lección en la carpeta de imágenes. Si tuvieras otro tipo de archivo con datos, que te gustaría enlazar, por favor, comunícaselo al editor.
-3. Una vez has sido añadido como colaborador, navega hasta la [carpeta de lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones), o a la [carpeta de traducciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/traducciones) del repositorio [ph-submissions]. A continuación, solo tienes que arrastrar y soltar el archivo de Markdown desde tu ordenador a la ventana del navegador. Si necesitas ayuda, por favor, consulta las [instrucciones de GitHub](https://help.github.com/articles/adding-a-file-to-a-repository/)). Haz clic sobre el botón verde "Commit Changes"; no hace falta que cambies el mensaje que sale por defecto.
-4. Seguramente tengas varias imágenes que acompañan a la lección. Asegúrate de que las imágenes hayan sido identificadas según las normas expuestas más arriba. Navega hasta la [carpeta de imágenes](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images) del [repositorio de envíos] [ph-submissions]. Haz clic en la carpeta que tiene el nombre de tu lección (que tu editor debería haber creado para ti; si no la encuentras, por favor, contacta con el editor asignado). Una vez has accedido a esta carpeta, arrastra y suelta todas las imágenes en la ventana del navegador, tal y como hiciste en el paso 3. No puedes arrastrar una carpeta de imágenes pero sí puedes seleccionar varios archivos a la vez.
-5. ¡Ya puedes visualizar tu lección! Normalmente GitHub tarda 5 minutos (o menos) en convertir los archivos Markdown en HTML. A continuación, navega hasta `http://programminghistorian.github.io/ph-submissions/lessons/` + `NOMBRE-DE-TU-LECCIÓN` (tras reemplazar el NOMBRE-DE-TU-LECCIÓN con el nombre de tu archivo).
-6. Ponte en contacto con tu editor para comunicarle que has subido los archivos al repositorio de envíos; los editores reciben una notificación pero mejor asegúrate de que no pasemos por alto tu envío.
+## Paso 3: Enviando una nueva lección
->Nota: Si estás familiarizado con la línea de comandos git y el respositorio GitHub, también puedes enviar tu lección y las imágenes mediante una solicitud de extracción (`*pull request*`) dirigida al repositorio `ph-submission` y combinar los archivos (en lugar de arrastrar y soltarlos como se acaba de describir). **¡Por favor, no envíes lecciones mediante una solicitud de extracción al repositorio Jekyll!** Enviando tu contribución al repositorio [ph-submissions], seremos capaces de controlar mejor los cambios y seguir el desarrollo de la lección o traducción.
+Una vez que tu archivo ha sido preparado de acuerdo con las especificaciones anteriores, ¡ya puedes enviárnoslo! Te sugerimos, de todos modos, que pidas al menos a dos personas que prueben tu lección y te den su opinión. Es muy importante que pruebes que es posible seguir el tutorial desde distintos sistemas operativos sin problema. Esto permitirá al equipo editorial centrarse en que produzcas una lección lo más sólida posible.
+En el GitHub de [Programming Historian](https://github.com/programminghistorian) mantemos dos repositorios (es decir, dos sitios en donde almacenar archivos y carpetas). Por un lado, el repositorio [jekyll](https://github.com/programminghistorian/jekyll), que contiene los archivos a los que se accede a través del navegador [web](/es). Por el otro, el repositorio llamado [ph-submissions](https://github.com/programminghistorian/ph-submissions), que es donde se realiza el proceso de edición de las lecciones.
-## ¡Enviado! ¿Y ahora qué?
+Debes enviar tu lección a través de una correo electrónico a tu editor/a, quien se encargará de subir todos los materiales al repositorio correspondiente en [GitHub](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones).
-Para saber qué ocurre tras enviar una traducción o lección, consulta nuestra [guía para editores](/es/guia-editor) en la que se detalla el proceso editorial. A continuación, resumimos el proceso.
+1. **Obtener acceso**: crea una [cuenta gratuita en GitHub](https://github.com/join). Envía tu nombre de usuario de GitHub a tu editor/a, quien te dará acceso al sitio de envíos. Si bien no harás la carga inicial en GitHub, necesitarás acceso para el proceso de revisión.
+2. **Prepara los materiales**: si tu lección incluye imágenes, asegúrate que todos los archivos están nombrados según las convenciones explicadas más arriba. Las imágenes debes enviarlas en una sola carpeta comprimida. Si tu lección incluye archivos de datos, estos deben ser enviados en otra carpeta comprimida.
+3. **Envía un correo electrónico a tu editor/a**: hazle saber a tu editor/a que tienes todo listo para el envío de tu lección. Este correo electrónico debe incluir el archivo .md de la lección y las carpetas comprimidas con las imágenes y datos, si corresponde.
+4. **Únete a la conversación**: tu editor/a subirá los archivos a nuestro [repositorio de envíos](https://github.com/programminghistorian/ph-submissions) y hará algunos cambios iniciales para asegurarse de que todo funciona bien. Además, abrirá un "ticket de revisión" para tu lección en la sección de *[issues](https://github.com/programminghistorian/ph-submissions/issues)* de ese repositorio.
+5. **Realiza las revisiones**: si bien la carga inicial de tu lección en el repositorio `ph-submissions` será realizada por tu editor/a, el proceso editorial requerirá que hagas modificaciones. Todas las ediciones posteriores deben ser hechas directamente por ti en ese repositorio para asegurarnos de que estás trabajando en la última versión del archivo.
-El paso más importante consiste en que tu editor cree un *[issue](https://github.com/programminghistorian/ph-submissions/issues)* para tu traducción o lección en el repositorio [ph-submissions], con un enlace a tu lección (que pre-visualizaste en el paso 5). El editor invitará a dos revisores (como mínimo) a que lean y comenten tu lección.
+## El proceso de revisión de pares
-### Espera los comentarios de tus revisores
+Tu editor/a comprobará que tus archivos se hayan cargado y formateado correctamente. En esta etapa se te enviará un enlace de vista previa donde se evidenciará cualquier error de formato para que puedas corregirlo. Las modificaciones debes hacerlas en el archivo .md de tu lección, que se encuentra en el [repositorio de propuesta de lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones).
-Nos comprometemos a completar el proceso de revisión en cuatro semanas; sin embargo, en ocasiones en ocasiones hay demoras y el proceso puede tomar más tiempo del que nos gustaría.
+La revisión de pares se registrará en un "[ticket](https://github.com/programminghistorian/ph-submissions/issues)" de GitHub, que actúa como una discusión abierta en el tablero de mensajes. Ten en cuenta que nuestra revisión de pares se realiza en público y se mantiene a disposición del público como un registro permanente del proceso editorial. Si tienes alguna preocupación o deseas solicitar una revisión cerrada, ponte en contacto con tu editor/a.
-A fin de promover una revisión por pares abierta y una investigación pública, animamos a todos los participantes a revisar y debatir la lección en GitHub. Al mismo tiempo, también queremos que todo el mundo se sienta cómodo con el proceso. Por eso si necesitas debatir algo en privado, [puedes contactar con tu editor](/es/equipo-de-proyecto) o con nuestra [*ombudsperson*](/project-team) María-José Afanador.
+El proceso de revisión por pares normalmente se realiza en tres etapas:
+1) Tu editor/a leerá y probará cuidadosamente tu lección, proporcionando una primera ronda de retroalimentación a la que se te pedirá que respondas. El propósito de esta primera ronda de retroalimentación es asegurarse de que tu lección responde a las necesidades de la audiencia de *Programming Historian* y de que los revisores externos reciban una lección que funcione. Normalmente se te dará un mes para responder a esta primera revisión.
-### Contesta
+2) Tu editor/a abrirá la lección para una revisión formal de pares. Esto incluirá al menos dos revisores que serán contactados por tu editor/a. La revisión también puede incluir comentarios de la comunidad más amplia, que son bienvenidos para contribuir con sus puntos de vista. Por lo general, tratamos de pedir a los revisores que aporten sus comentarios en el plazo de un mes, pero a veces circunstancias imprevistas hacen que esto no sea posible. Tu editor debe dejarte claro que no debes responder a las sugerencias de cambios hasta después de que se hayan publicado ambas y que el editor haya resumido y dado instrucciones claras para seguir adelante. En algunos casos esto puede ser una sugerencia para revisar sustancialmente o repensar la lección. En otros casos será cuestión de hacer algunos cambios menores. En función de los comentarios de la revisión de pares y de la naturaleza de las cuestiones planteadas, puede ser necesario revisar el tutorial más de una vez. En todo momento tu editor se esforzará porque tengas claros los pasos necesarios para que la lección sea publicable. Siempre tendrás la opción de retirarte del proceso de revisión si así lo deseas.
-Tu editor y los revisores sugerirán cambios para mejorar la lección o traducción escrita por ti. El editor debiera aclarar qué sugerencias son esenciales, cuáles son opcionales, y cuáles se pueden desestimar.
+3) Una vez que editor/a y revisores estén conformes con el texto, tu editor/a recomendará la publicación a la jefa de redacción, quien leerá el tutorial para asegurarse de que cumpla con los lineamientos y estándares de esta Guía. En algunos casos, esta etapa puede considerar revisiones adicionales o edición de estilo para que el artículo se ajuste a nuestras normas de publicación. Si la jefa de redacción está satisfecha con tu lección, esta será trasladada al repositorio que aloja el sitio web de Programming Historian para su publicación. Tu editor/a te informará de cualquier información adicional que se requiera en esta etapa (por ejemplo, cómo quieres que aparezca tu nombre y afiliación institucional en la lección).
-Puedes editar tus archivos en GitHub, siguiendo estas [instrucciones](https://help.github.com/articles/editing-files-in-your-repository/).
+Puede resultarte útil leer nuestra [Guía para editores](/es/guia-editor), donde se detalla nuestro proceso editorial.
-Tus revisiones deberían estar completadas al cabo de cuatro semanas de recibir los comentarios de tu editor. Con esta medida pretendemos que las lecciones se publiquen en un margen de tiempo adecuado y que el proceso no se alargue de manera innecesaria. Si prevees que no podrás completar los cambios en el tiempo acordado, por favor, contacta con tu editor para establecer una nueva fecha límite.
+Si en algún momento no tienes seguridad sobre cuál es tu papel en ese momento o de lo que debes hacer a continuación, publica una pregunta en el ticket de revisión de tu lección. Nuestro equipo editorial responderá lo antes posible. Nos esforzamos por responder a todas las preguntas en unos pocos días.
-En cualquier momento del proceso, si no estás seguro o segura de cuál es tu rol o de qué deberías hacer, también puedes comunicarte con tu editor. Asimismo, te animamos a preguntarnos en forma de mensaje en el *issue* creado a propósito de tu traducción o lección. A veces podemos demorarnos en contestar, pero esperamos que los cambios propuestos sirvan para mejorar tu contribución.
+### Haznos responsables
+Nuestro equipo voluntario trabaja duro para proporcionar a autores y autoras una revisión entre pares rigurosa, colegiada y eficiente. Sin embargo, reconocemos que hay momentos en que las expectativas pueden no cumplirse. Queremos que quienes participan en este proceso se sientan con el poder de exigirnos altos estándares. Si, por cualquier razón, sientes que has sido tratado/a injustamente, que el proceso te parece confuso, que la revisión se ha retrasado innecesariamente, que un revisor ha sido grosero, que tu editor/a no ha sido lo suficientemente receptivo/a o tienes cualquier otra inquietud, por favor, déjanos saber para que podamos abordarlo de manera proactiva.
-### Comunica a tu editor que has terminado y envíale una breve biografía
+Plantear una preocupación NO afectará negativamente el resultado de tu revisión de pares, incluso si se trata de una revisión de pares en curso.
-Una vez has finalizado con los cambios sugeridos, ponte en contacto con tu editor. A continuación, si no lo has hecho ya, envía un texto biográfico breve (de 2 o 3 frases) para que se publique al final de la lección traducida o creada por ti.
+Para plantear una preocupación, por favor contacta a una de las siguientes personas, según te resulte más cómodo:
-Finalmente, el equipo editorial the *The Programming Historian en español* revisará que hayas introducido los cambios necesarios y moverá el archivo desde el repositorio `ph-submissions` al repositorio `jekyll`, y actualizará el directorio de lecciones.
+* El editor o editora de tu lección
+* La [jefa de redacción](/es/equipo-de-proyecto)
+* Nuestra ombudsperson independiente, [Silvia Gutiérrez de la Torre](/es/equipo-de-proyecto)
-¡Felicidades! ¡Ya has publicado tu traducción o lección en *The Programming Historian en español*!
+Esperamos que no te encuentres en una situación incómoda, pero si esto sucede, te agradecemos que nos ayudes a mejorar.
+---
-[traducciones pendientes]: https://github.com/programminghistorian/ph-submissions/blob/gh-pages/es/lista-de-traducciones.md
-[lecciones ya publicadas]: /es/lecciones
-[directrices para revisores]: /es/guia-para-revisores
-[lecciones en desarrollo]: https://github.com/programminghistorian/ph-submissions/tree/gh-pages/lessons
- [Ian Milligan]: mailto:i2millig@uwaterloo.ca
- [Lesson Pipeline wiki page]: https://github.com/programminghistorian/jekyll/wiki/Lesson-Pipeline
- [reviewer guidlines]: /reviewer-guidelines.html
- [published lessons]: lessons
- [TextWrangler]: http://www.barebones.com/products/textwrangler/
- [Notepad++]: https://notepad-plus-plus.org/
- [project team]: /project-team.html
- [slug]: https://en.wikipedia.org/wiki/Semantic_URL#Slug
- [YAML]: https://es.wikipedia.org/wiki/YAML
- [GitHub Guide to Markdown]: https://guides.github.com/features/mastering-markdown/
- [Markdown Basics]: https://help.github.com/articles/markdown-basics
- [Github Flavored Markdown]: https://help.github.com/articles/github-flavored-markdown
- [the raw text on GitHub]: https://raw.githubusercontent.com/programminghistorian/jekyll/gh-pages/new-lesson-workflow.md
- [elements provided by HTML5]: http://html5doctor.com/the-figure-figcaption-elements/
- [ilustración de ejemplo]: https://github.com/programminghistorian/jekyll/commit/476f6d466d7dc4c36048954d2e1f309a597a4b87#diff-f61eee270fe5a122a0163ebf0e2f8725L28
- [versión en línea]: /lessons/automated-downloading-with-wget#lesson-goals
- [sintaxis extendida]: http://kramdown.gettalong.org/syntax.html#tables
- [pandoc]: http://johnmacfarlane.net/pandoc/
- [insertar código aquí]: https://help.github.com/articles/github-flavored-markdown/#fenced-code-blocks
- [pull request]: https://help.github.com/articles/using-pull-requests/
- [GitHub for Mac]: https://mac.github.com/
- [GitHub for Windows]: https://windows.github.com/
- [Create an account]: https://help.github.com/articles/signing-up-for-a-new-github-account/
- [naming conventions described above]: #name-the-lesson-file
- [pending pull requests on our repo]: https://github.com/programminghistorian/jekyll/pulls
- [GitHub Guides]: https://guides.github.com/activities/forking/
- [forking]: https://help.github.com/articles/fork-a-repo/
- [independent tutorials]: https://gun.io/blog/how-to-github-fork-branch-and-pull-request/
- [Git for Philosophers]: https://github.com/rzach/git4phi
- [GitHub Pages]: https://pages.github.com
- [ph-submissions]: https://github.com/programminghistorian/ph-submissions
+La versión en inglés de esta guía de estilo fue creada con el apoyo de la Escuela de Humanidades de la Universidad de Hertfordshire. Esta traducción y adaptación al español es producto del trabajo conjunto del Equipo Editorial de Programming Historian en español.
diff --git a/es/guia-para-traductores.md b/es/guia-para-traductores.md
new file mode 100644
index 0000000000..ec51b41dfa
--- /dev/null
+++ b/es/guia-para-traductores.md
@@ -0,0 +1,308 @@
+---
+title: Guía para traductores
+layout: blank
+redirect_from:
+ - /new-lesson-workflow
+ - /translator-guidelines
+skip_validation: true
+---
+
+# Guía para traductores
+
+
+
+
+
+Estas directrices han sido desarrolladas para ayudarte a entender el proceso de traducción de un tutorial para *Programming Historian* en Español. Incluyen detalles prácticos sobre el proceso de traducción de un tutorial, así como indicaciones sobre el flujo de trabajo y el proceso de revisión entre pares. Si en algún momento hay algo que no te queda claro, por favor envía un correo electrónico a {% include managing-editor.html lang=page.lang %}.
+
+## Paso 1: Proponer una nueva traducción
+
+Si quieres traducir una lección, por favor, revisa la lista de [traducciones pendientes](https://github.com/programminghistorian/ph-submissions/blob/gh-pages/es/lista-de-traducciones.md) y ponte en contacto con {% include managing-editor.html lang=page.lang %}. Buscamos traducciones rigurosas, de lectura amena y que, además, tengan en cuenta el contexto de América Latina y España, así como los recursos que se encuentra disponibles actualmente en lengua española.
+
+Una vez aceptada tu propuesta y para asegurar la publicación oportuna, te pedimos que entregues tu traducción al cabo de 90 días tras la aprobación. Durante este período de 90 días, tu punto de contacto será la jefa de redacción o el editor o editora que haya sido asignada para acompañarte durante el proceso.
+
+## Paso 2: Escribir y formatear el tutorial
+Esta guía de estilo define un conjunto de normas para ser utilizadas al traducir lecciones al español para *Programming Historian*. Al seguir estos lineamientos nos ayudas a asegurar que el contenido sea consistente y accesible.
+
+La guía contempla tres secciones, que deben ser leídas antes y después de la escritura:
+
+* A. Estilo y audiencia
+* B. Pautas específicas de escritura
+* C. Guía de formato
+
+## A. Estilo y audiencia
+Esta primera sección se ocupa de cuestiones de estilo generales que te ayudarán a tomar decisiones que satisfagan las necesidades de nuestra audiencia y editores. Incluimos información básica sobre el estilo y el tono, el acceso abierto y los valores del código abierto, información sobre la escritura para una audiencia global, la escritura sostenible y la toma de decisiones inteligentes sobre los datos utilizados en las lecciones. Lee esta sección antes de traducir la lección. Vuelve a leerla antes de enviarla para asegurarte de que el tutorial cumple con estos requisitos.
+
+### Lenguaje y estilo
+* Mantén un tono formal, pero accesible.
+* Habla con tu lector en segunda persona singular (tú).
+* Procura escribir de un modo comprensible y adecuado para hablantes de español de distintas zonas geográficas.
+* Refiérete a tu escrito como "tutorial" o "lección", no como "artículo".
+
+### Escribe para una audiencia global
+*Programming Historian* es leído por personas que viven en todo el mundo. Es por ello que debes tomar medidas para que tu traducción sea accesible para el mayor número de personas posible. Las siguientes directrices te ayudarán a enfrentar una audiencia global:
+
+* Escribe teniendo en cuenta que la lección será leída por hispanoablantes de distintas regiones y culturas.
+* **Datos:** si es posible deben ser traducidos. En algunos casos, quienes traducen la lección han decidido modificarlos para adaptar la lección al español. Un caso de esto es la lección [Introducción a Topic Modeling y MALLET](/es/lecciones/topic-modeling-y-mallet), en que se cambió el corpus utilizado en la lección original por uno en español. Esto fue posible ya que no afectaba mayormente el texto del tutorial. En otros casos, se ha preferido traducir los datos (por ejemplo, traducir los nombres de variables y observaciones de un dataframe).
+* **Términos técnicos:** siempre deben estar vinculados a [Wikipedia](https://es.wikipedia.org/), a un diccionario fiable o a un sitio web sostenible, en primera instancia. Un término técnico es cualquier palabra que una persona en la calle puede no conocer o entender. Si la lección original tiene vínculos en inglés, busca un equivalente en español para incluir en la traducción.
+* **Referencias culturales**: es probable que la lección contenga enlaces para dar contexto a las referencias culturales. Busca versiones en español para incluir en la lección traducida. Si hay referencias que consideres que necesitan una explicación adicional para el público hispanoparlante, inclúyela como nota.
+* **Lenguaje racial y étnico**: use la terminología racial cuidadosamente y con especificidad. Los términos históricos que ya no se utilizan deben usarse solo en su contexto histórico y solo cuando sea necesario. Usa los términos raciales como adjetivos y no como sustantivos: personas blancas en lugar de "blancos", una mujer asiática en lugar de "una asiática". Ten en cuenta que los términos pueden entenderse de manera diferente en distintos países y que lo que has aprendido como un uso correcto o sensible puede ser culturalmente específico de tu país (por ejemplo, no todas las personas de ascendencia africana son "afroamericanos". Algunos de ellos son africanos, o negros británicos, o caribeños, etc.). Asimismo, las personas del Reino Unido entenderán el término "asiático" (India, Pakistán, Bangladesh) de manera diferente a las de América del Norte (por ejemplo, China, Japón, Vietnam, Tailandia).
+* **Expresiones idiomáticas**: muchas expresiones no son traducibles de manera literal. En esos casos, propón una traducción que permita entender el sentido de la expresión original. Por ejemplo: _it’s raining cats and dogs_ > _está lloviendo a cántaros_.
+* **Repetición léxica en traducciones desde el inglés**: en español tenemos la flexibilidad de poder omitir el sujeto, ya que por contexto (marcas de persona, género y número) se suele entender a qué nos estamos refiriendo. Es importar tener esto en cuenta en traducciones desde el inglés para evitar que el texto sea repetitivo. Por ejemplo, _The first argument is the name of the data frame. The second and subsequent arguments are the expressions that filter the data frame._ > _El primer argumento es el nombre del data frame. El segundo y los subsiguientes son las expresiones para filtrarlo_.
+* **Modos y tiempos verbales en traducciones desde el inglés**: el español tiene mayor variedad de conjugaciones verbales que el inglés. Al traducir, por lo tanto, se debe priorizar la forma verbal que sea mejor para expresar el sentido del fragmento en español, no la que parezca ser literal del inglés. Es importante tener en cuenta esto en particular con el subjuntivo en español. Por ejemplo: _This doesn't imply that you have a good model and it certainly doesn't imply that the model is "true"_ > _Esto no implica que_ tengas _un buen modelo y, ciertamente, no implica que el modelo_ sea _"verdadero"_.
+
+## B. Pautas específicas de escritura
+En esta segunda sección se abordan cuestiones más específicas del estilo de escritura, como qué palabras utilizar, cómo usar la puntuación o qué formato utilizar para fechas y números. Lee esta sección antes de hacer la traducción, ya que este tipo de lineamientos no son iguales en todos los idiomas, por eso es importante que los tengas en cuenta. Vuelve a leerlos al terminar para chequear que tu texto se ajusta a ellos.
+
+### Fechas y hora
+ * Para siglos, utiliza números romanos. Evita frases centradas en lo nacional, como "el largo siglo XVIII", que tienen un significado específico para los especialistas británicos del siglo XVIII, pero para nadie más.
+ * Para décadas escribe "los años cincuenta" o "los cincuenta" (no "los años 50's" o "la década de los 50s").
+ * Comprime las secuencias de fecha así: 1816-17, 1856-9, 1854-64.
+ * Para fechas escritas en forma numérica utiliza el formato AAAA-MM-DD, conforme al estándar ISO 8601:2004. Esto evita la ambigüedad.
+ * Utiliza a. C. (‘antes de Cristo’) o d. C. (‘después de Cristo’): 211 a. C., 123 d. C.
+ * Para horas: 1 a.m., 6:30 p.m. Es preferible diez de la noche o 10 p.m. antes que 10 de la noche.
+
+### Números
+ * Se escriben con palabras los números:
+ - que pueden expresarse en una sola palabra (del cero al veintinueve, las decenas como treinta, cuarenta, etc.) y las centenas (cien, doscientos, etc.)
+ - los números redondos que pueden expresarse en dos palabras (quinientos mil, etc)
+ - los números que se expresan en dos palabras unidas por una conjunción y hasta noventa y nueve.
+ En caso de que tengas dos referencias numéricas que supongan distintos formatos, elige uno solo para ser consistente (cinco manzanas y cien naranjas; 5 manzanas y 110 naranjas).
+ * Al escribir números de más de cuatro cifras sepáralas en grupos de tres dígitos desde la derecha dejando un espacio (no puntos ni comas). Por ejemplo, 32 904, no 32904, 32.904 o 32.904. Excepciones: años, páginas, versos, portales de vías urbanas, apartados de correos, números de artículos legales, decretos o leyes.
+ * Para separar la parte entera de la decimal debe usarse la coma (1,5). Esto no aplica para código escrito en algún lenguaje de programación, ya que muchas veces estos se rigen por el criterio para la lengua inglesa (que usa punto como separador de coma).
+ * Usa numerales para hacer referencia a versiones (versión 5 o v.5).
+ * Al referirte a porcentajes, utiliza el símbolo % con numerales y la expresión _por ciento_ cuando escribes el cifra con palabras (por ejemplo, _5%_ o _cinco por ciento_. No _5 porciento_ o _cinco %_). En porcentajes inferiores a 1, agrega un cero antes de la coma decimal (0,05%)
+ * Utiliza el [formato LaTeX para fórmulas matemáticas](https://davidhamann.de/2017/06/12/latex-cheat-sheet/).
+ * Para unidades de medida utiliza el sistema métrico.
+
+### Listas
+Típicamente, usamos listas numeradas y listas con viñetas. Los elementos de la lista comienzan con mayúscula. Los elementos de la lista deben ser tratados como elementos separados y no deben ser encadenados con puntuación o conjunciones.
+
+Sin estilo apropiado:
+
+* Acá hay un ítem y
+* acá hay otro ítem; y
+* acá hay un ítem final.
+
+Con estilo:
+
+* Acá hay un ítem
+* Acá hay otro ítem
+* Acá está el último ítem
+
+### Puntuación
+ * **Abreviaturas, acrónimos y siglas**: escribe la palabra completa la primera vez que la utilizas, por ejemplo, «Humanidades Digitales (HD)». Las siglas son invariables cuando se enunician en plural («las ONG») y adoptan el género de la palabra que constituye el núcleo de la expresión abreviada, que normalmente ocupa el primer lugar en la denominación: el FMI, por el «Fondo» Monetario Internacional; la OEA, por la «Organización» de Estados Americanos. Las siglas se escriben sin puntos o espacios en blanco como separación: RAE, OEA, etc. (no R.A.E. u O E A). Normalmente se escriben en mayúscula todas las letras que componen una sigla (OCDE, APA, ISO) y, en ese caso, no llevan nunca tilde, incluso en casos en que la norma ortográfica indicaría su uso (como en CIA).
+ * **Paréntesis**: se usa para insertar en un enunciado una información complementaria o aclaratoria, ej: El dijo: «Cuando lo acaben (el túnel) revolucionará la forma de viajar» or «Ella dijo goodbye (adios)». Ubica el punto fuera del paréntesis de cierre si lo que está dentro de él no es una oración completa (como este caso). (Una oración independiente, en cambio, lleva el punto final antes del paréntesis de cierre.)
+ * **Dos puntos**: se utilizan para introducir listas, ejemplificaciones, aclaraciones, citas textuales, etc., como en estos ejemplos:
+ * El comité recomienda: ampliar las horas de licencia hasta la medianoche; permitir a los niños en los locales con licencia; relajar los controles de planificación en los nuevos establecimientos públicos.
+ * Después de dos puntos va minúscula: así es como lo hacemos.
+ * **Raya**: para encerrar aclaraciones o incisos.
+ * **Guión**: se usa como signo de unión entre palabras y como signo de división de palabras a final de línea.
+ * **Puntos suspensivos**: van pegados a la palabra que los precede y separados de la que los sigue. Cuando se utilizan para condensar una cita directa, van entre paréntesis o corchetes.
+ * **Signos de exclamación**: se utilizan al comienzo y al final de la exclamación.
+ * **Punto**: se escribe punto después de las abreviaturas, pero no de las siglas o acrónimos.
+ * **Comillas angulares**: en los textos impresos, se recomienda utilizar en primera instancia las comillas angulares « », (ejemplo: «Antonio me dijo: “Vaya ‘cacharro’ que se ha comprado Julián”»). Se reservan los otros tipos para cuando se debe entrecomiilar un texto ya entrecomillado.
+
+### Mayúsculas
+La pauta es usarlas con moderación en la prosa corriente. Reglas específicas:
+
+* **Títulos**: los encabezados y títulos de libros llevan mayúscula en la primera letra del título: »Preparando los datos para el análisis»; *El orgullo y la pasión*.
+* **Siempre con mayúscula inicial**:
+ * **Nombre propios**: William J. Turkel – a menos que la persona elija deletrear su nombre de otra manera (por ejemplo "bell hooks").
+ * **Organizaciones, organismos, entidades, partidos políticos, etc**: Museo de Arte Moderno, Casa de Cervantes, Biblioteca Nacional, Agencia Nacional de Tierras, Naciones Unidades. Las palabras de función dentro del nombre no llevan mayúsculas en estos casos.
+ * **Días festivos y festivales**: Diwali, Hanukkah, Eid-Ul-Adha, Día de los Muertos.
+* **A veces o solo parcialmente en mayúsculas**:
+ * **Lugares**: capitales de países, regiones, zonas reconocibles (por ejemplo, el Oriente Medio, Senegal). Minúsculas para los puntos cardinales, a excepción de cuando son utilizados como parte del nombre de un lugar (para llegar al Polo Norte, dirigirse al norte). Otros ejemplos son: el noreste de Kenya, el sur del Brasil, el oeste, el oeste del Canadá, el extremo oriental, el Asia sudoriental, América Central, América Latina.
+ * **Eventos históricos**: mayúscula inicial, como en Primera Guerra Mundial, Segunda Guerra Mundial; Guerra de Crimea/Boer/Vietnam/del Golfo; Guerra de los Cien Años.
+ * **Religión**: minúscula, como en anglicano/a, bautista, budista, católico/a, cristiano/a, hindú, metodista, musulmán/a, protestante, católico/a romano/a, sikh, y también para evangélicos/as, carismáticos/as, ateos/as.
+ * **Disciplinas**: Se escriben con minúscula, salvo cuando hacen referencia a nombres de asignaturas, carreras, departamentos, etc.
+ * **Libros sagrados (selección)**:
+ * **Biblia**: mayúscula si se refiere al Antiguo o al Nuevo testamento.
+ * **Budismo**: sutras (sermones) y abhidhamma (análisis e interpretación). Para el budismo tibetano tambien hay libros tántricos y Libro tibetano de los muertos.
+ * **Hinduismo**: los Śruti: Vedas, Samhitas, Brahmanas, Aranyakas, Upanishads; los Vedāngas, épica Hindú, sutras, shastras, textos filosóficos, los Puranas, literatura kāvya, los Bhasyas, muchos nibandhas.
+ * **Judaismo**: el Tanakh (Torá, Nevi'im, Ketuvim), el Talmud (Mishná, Guemará)
+ * **Corán**: textos que incluyen los hadiz, el Tawrat (Torá), Zabur (posiblemente salmos), Injil (1.2 billones).
+ * **Sikh**: Adi Granth (comúnmente llamado el Sri Guru Granth Sahib Ji), el Dasam Granth, los Varan Bhai Gurdas, los textos del Bhai Nand Lal.
+ * **Trabajos**: en minúscula – presidente Macron, Emmanuel Macron, presidente de Francia. El ministro de Hacienda. El Papa se escribe con mayúscula y la reina en minúscula.
+ * **Organizaciones e instituciones**: el gobierno (en minúscula en toda referencia), el gabinete (minúscula en toda referencia), la Iglesia de Jesucristo de los Santos de los Últimos Días ("la iglesia"), Ministerio de Educación ("el ministerio"), Universidad Católica ("la universidad"), el Tribunal de Apelación ("tribunal de apelación" o "el tribunal").
+ * **Universidades e institutos**: mayúsculas para la institución y para departamentos ("Universidad Autónoma de México", "Departamento de Historia").
+* **Siempre en minúscula**:
+ * **Días de la semana y meses**: martes, diciembre.
+ * **Estaciones**: primavera, verano, otoño, invierno.
+ * **Tipos de cambio**: peso, sol, euro, franco, marco, dong, etc.
+
+
+### Casos especiales y otros elementos a tener en cuenta
+* La palabra _solo_ y los demostrativos no se tildan.
+* Las voces latinas terminadas en _t_ o _m_ forman el plural en español agregando una ese. Se desaconseja usar, como sucede por influjo del inglés, el plural latino: el plural de _currículum_ es _currículums_, no _currícula_). En la misma línea, la palabra _corpus_ es invariable en plural, por lo que no debe utilizarse _corpora_ como plural.
+* La expresión correcta es _en relación con_ o _con relación a_, no _en relación a_.
+* La conjunción es _sobre la base de_ o _con base en_, no _en base a_.
+
+
+### Referencias
+* Si existe una versión en español de alguna de las referencias utilizadas en la lección, incluye esa.
+* Asegúrate de que las frases vinculadas tengan un significado semántico. No enlaces términos que son significativos solo para usuarios videntes como "haz clic aquí".
+* Toda la literatura tradicional y académica debe incluirse como nota al final, en lugar de como enlace.
+* Los superíndices de las notas finales deben ir dentro de la puntuación final: así². No afuera: así.²
+* Utiliza el sistema de "Notas y Bibliografía" que se encuentra en el [Manual Chicago Manual 17a edición](https://uc3m.libguides.com/guias_tematicas/citas_bibliograficas/chicago) para las notas al final.
+* Cuando se mencione por primera vez una obra publicada, incluye el nombre del autor (incluyendo el primer nombre). Por ejemplo, «Puedes encontrar más información en *The Elements of Typographic Style* de Robert Bringhurst» o «Para más información, consulta *The Elements of Typographic Style* de Robert Bringhurt». En las referencias posteriores, usa solo el título del libro. Los nombres de los autores pueden ser acortados a apellidos solo a partir de su segunda mención.
+* Las notas finales no pueden contener solo una URL.
+ * (Correcto): Grove, John. "Calhoun and Conservative Reform." *American Political Thought* 4, no. 2 (2015): 203–27. https://doi.org/10.1086/680389.
+ * (Incorrecto): https://doi.org/10.1086/680389.
+
+### Lenguaje inclusivo y no discriminatorio
+En Programming Historian nos comprometemos a publicar tutoriales que no reproduzcan lenguaje sexista y discriminador. Te pedimos que tengas en cuenta las siguientes recomendaciones:
+
+* Al referirte a personas o grupos de personas que presentan algún tipo de discapacidad, evita los binarismos normal/anormal, capaz/incapaz y términos como "capacidades diferentes" e "incapacidad".
+* No te refieras a pueblos y comunidades indígenas con términos que son considerados despectivos o que no son los que sus miembros prefieren utilizar. Por ejemplo, prefiere inuit frente a "esquimal", o mapuche frente a "araucano".
+* Cuando sea posible, sustituye el masculino genérico por un sustantivo que denomine sin una carga de género al colectivo de personas, a la profesión, a la institución o al lugar.
+Por ejemplo, "la audiencia", en vez de "los lectores"; "el parlamento" en vez de " los parlamentarios".
+* Haz cambios en la redacción que eviten tener que utilizar un sustantivo o adjetivo con flexión de género. Por ejemplo, "este punto ha sido muy importante para los historiadores" podría reescribirse como "este punto ha sido muy importante en una disciplina como la historia".
+* Utiliza la forma femenina cuando el referente es una mujer: la presidenta, no la presidente; la jueza, no la juez.
+* Utiliza la palabra persona o personal más un adjetivo para referirte a un grupo y evitar así la forma masculina. Por ejemplo, en ciertos contextos "los docentes" puede remplazarse por "el personal docente".
+* También es posible desdoblar los sustantivos y adjetivos en en femenino y masculino (por ejemplo, "los autores y autoras"). Sin embargo, recomendamos utilizar este recurso con moderación, ya que en ocasiones su uso excesivo hace la lectura de un texto menos fluida.
+
+
+## C. Guía de formato
+Esta última sección abarca cuestiones de formato para el envío de tu traducción. Lee esta sección antes y después de escribir tu borrador. Si te equivocas en alguno de estos elementos, podrás corregirlo cuando publiquemos un avance en línea de tu lección al comienzo del proceso de revisión de pares.
+
+### Escribe en Markdown
+Todas las lecciones deben ser escritas en [Markdown](https://es.wikipedia.org/wiki/Markdown). Tu editor/a te indicará dónde puedes encontrar el archivo de la lección original para que trabajes sobre él.
+
+Markdown es un lenguaje de marcado que se crea mejor con un editor de texto. MS Word y Open Office NO son editores de texto y deben ser evitados. Recomendamos [Atom](https://atom.io/), [TextWrangler](https://www.barebones.com/products/textwrangler/), [TextEdit](https://en.wikipedia.org/wiki/TextEdit), [MacDown](https://macdown.uranusjr.com/), [Notepad++](https://notepad-plus-plus.org/download) o [Sublime Text](https://www.sublimetext.com/).
+Para una introducción sencilla a Markdown puedes ver la lección [Introducción a Markdown]({{site.baseurl}}/es/lecciones/introduccion-a-markdown) o la referencia concisa [GitHub Guide to Markdown](https://help.github.com/es/github/writing-on-github/basic-writing-and-formatting-syntax).
+
+Tu lección debe ser guardada en formato .md. El nombre del archivo de tu lección se convierte en parte de la URL de la lección, por lo tanto, debe ser nombrado de acuerdo a las siguientes reglas:
+
+ * Un nombre corto, en minúsculas, descriptivo y que dé una clara indicación del contenido de la lección (por ejemplo, introduccion-a-markdown.md).
+ * No utilices espacios ni guiones bajos en el nombre del archivo; utiliza guiones.
+ * Utiliza un nombre de archivo rico en palabras clave que incluyan las tecnologías o métodos usados en la lección (por ejemplo, Python o Análisis de Sentimientos).
+ * No utilices caracteres especiales, como tildes o ñ.
+
+### Negrita, cursiva y subrayado
+Para asegurar la consistencia de las lecciones, sigue las siguientes directrices de formato de texto:
+
+#### Negrita
+ * La negrita no se usa excepto en circunstancias excepcionales.
+ * La negrita se formatea utilizando **\*\*doble asterisco\*\***.
+
+#### Cursiva
+* Usa la cursiva para los títulos de libros, películas, programas de TV, pinturas, canciones, álbumes y sitios web.
+* Nunca uses la cursiva para nombres de empresas (el sitio web *Facebook* es propiedad de Facebook).
+* No uses la cursiva en los títulos de secciones, incluso si te estás refiriendo título de un libro.
+* La cursiva se formatea utilizando *\*un asterisco\**.
+
+#### Subrayado
+ * No se utiliza.
+
+### Alertas y advertencias
+Si quieres incluir un aparte o una advertencia, puedes hacerlo con el siguiente código:
+
+```
+
+¡Asegúrate se seguir cuidadosamente las instrucciones!
+
+```
+
+Este tipo de recurso puede ser útil para advertir a la audiencia sobre posibles dificultades o resultados diferentes producto de usar un sistema operativo, herramienta o datos en español.
+
+### Figuras e imágenes
+Las imágenes pueden ayudar a tu audiencia a entender los pasos de la lección, pero no deben ser usadas como decoración. Si la lección que vas a traducir tiene imágenes, verás que estas están etiquetadas secuencialmente siguiendo el patrón `nombre-leccion1.jpg`, `nombre-leccion2.jpg`, etc., y que en el texto son referidas como "Figura 1", "Figura 2", y así sucesivamente. Si decides incluir versiones en español de esas mismas imágenes (por ejemplo, porque tradujiste los datos o existe versión en español de la interfaz de la herramienta utilizada), estas deben seguir su propia numeración correlativa, es decir, `nombre-traduccion1.jpg`, `nombre-traduccion2.jpg`. Todas las figuras deben venir con una leyenda concisa y notas finales cuando sea apropiado. Debes tener el derecho legal para publicar cualquier imagen que incluyas.
+
+Utiliza formatos de archivos amigables para la web, como .png o .jpg, y reduce las imágenes grandes a un máximo de 840 px en el lado más largo. Esto es importante para lectores en países con velocidades de Internet más lentas.
+
+Las imágenes deben guardarse en una carpeta con el mismo nombre que el archivo .md de la lección. El editor o editora asignada a tu lección te ayudará a subir las imágenes cuando las envíes.
+
+Para insertar una imagen en tu texto, se utiliza el siguiente formato. Salvo que agregues una imagen adicional, solo correspondería traducir el pie de foto. Si agregas versiones traducidas de las imágenes existentes, no olvides cambiar el nombre del archivo con la imagen.
+
+{% raw %}
+``` markdown
+{% include figure.html filename="NOMBRE-ARCHIVO-IMAGEN" caption="PIE DE FOTO UTILIZANDO COMILLAS \"ESCAPADAS\"" %}
+```
+{% endraw %}
+
+Ten en cuenta que las comillas internas en el pie de foto deben escaparse con una barra invertida, como en el ejemplo anterior. Es posible que las imágenes no aparezcan en las vistas previas de la lección, pero tu editor/a se asegurará de que se reproduzcan correctamente cuando esta se publique.
+
+### Ejemplos de código
+Las líneas de código deben tener un formato que las distinga claramente de la prosa:
+
+ * Las líneas de código deben tener un máximo de 80 caracteres
+ * Los bloques de código de varias líneas deben estar encerrados en tres \`\`\`comillas invertidas\`\`\`
+ * El código dentro del texto (raramente usado) puede ser encerrado en una sola \`comilla invertida\`
+
+
+```
+El bloque de código se verá así
+```
+` y así` el código dentro del texto.
+
+
+Sigue las mejores prácticas para escribir tu código:
+
+* **Nombres de variables y funciones**: los nombres de variables deben ser sustantivos (por ejemplo, "nombre_coleccion") y los nombres de funciones verbos (por ejemplo, "crear_archivo"). Elije nombres concisos y significativos. Puedes usar el formato [snake_case](https://en.wikipedia.org/wiki/Snake_case) o [camelCase](https://en.wikipedia.org/wiki/Camel_case); lo importante es que seas consistente a lo largo de la sección.
+* **Comandos a editar**: cuando hagas referencia a texto que quieres que el usuario remplace con su propia información, utiliza MAYÚSCULAS rodeadas de ` tildes graves ` (por ejemplo, \`NOMBRE USUARIO ACÁ\`).
+* **Nombres de archivos**: los nombres de archivos que solicites crear en tu lección deben estar rodeados de tildes graves cuando se mencionan en el texto y deben incluir la extensión del archivo. Elije nombres concisos y significativos. Puedes usar [snake_case](https://en.wikipedia.org/wiki/Snake_case) o [camelCase](https://en.wikipedia.org/wiki/Camel_case); lo importante es que seas consistente (por ejemplos, `datos.txt`, `datosLimpios.py`, `grafico_autores.png` etc).
+* **Palabras reservadas**: los términos que son parte de un lenguaje de programación deben estar formateados como `código` usando tildes graves cuando los menciones en el texto. A continuación encontrarás una lista de nombres reservados de algunos lenguajes de programación comunes:
+
+#### JavaScript:
+
+`abstract`, `arguments`, `await`, `Boolean`, `break`, `byte`, `case`, `catch`, `char`, `class`, `const`, `continue`, `debugger`, `default`, `delete`, `do`, `double`, `else`, `enum`, `eval`, `export`, `extends`, `false`, `final`, `finally`, `float`, `for`, `function`, `goto`, `if`, `implements`, `import`, `in`, `instanceof`, `int`, `interface`, `let`, `long`, `native`, `new`, `null`, `package`, `private`, `protected`, `public`, `return`, `short`, `static`, `super`, `switch`, `synchronized`, `this`, `throw`, `throws`, `transient`, `true`, `try`, `typeof`, `var`, `void`, `volatile`, `while`, `with`, `yield`.
+
+#### Python 3:
+`and`, `as`, `assert`, `break`, `class`, `continue`, `def`, `del`, `elif`, `else`, `except`, `False`, `finally`, `for`, `from`, `global`, `if`, `import`, `in`, `is`, `lambda`, `nonlocal`, `None`, `not`, `or`, `pass`, `raise`, `return`, `True`, `try`, `while`, `with`, `yield`.
+
+#### R:
+`break`, `else`, `for`, `FALSE`, `function`, `if`, `in`, `Inf`, `NA`, `NA_character_`, `NA_complex_`, `NA_integer_`, `NA_real_`, `NaN`, `next`, `NULL`, `repeat`, `TRUE`, `while`, `...` y `..1`, `..2`, etc.
+
+
+## Paso 3: Enviando una nueva traducción
+
+Una vez que tu archivo ha sido preparado de acuerdo con las especificaciones anteriores, ¡ya puedes enviárnoslo! Te sugerimos, de todos modos, que pidas a un par de personas que lean tu traducción y te den su opinión.
+
+En el GitHub de [Programming Historian](https://github.com/programminghistorian) en GitHub mantenemos dos repositorios (es decir, dos sitios en donde almacenar archivos y carpetas). Por un lado, el repositorio [jekyll](https://github.com/programminghistorian/jekyll), que contiene los archivos a los que se accede a través del navegador [web](/es). Por el otro, el repositorio [ph-submissions](https://github.com/programminghistorian/ph-submissions), que es donde se realiza el proceso de edición de las lecciones originales y traducciones.
+
+Debes enviar tu traducción a través de una correo electrónico a tu editor/a, quien se encargará de subir todos los materiales al repositorio correspondiente en [GitHub](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/traducciones).
+
+1. **Obtener acceso**: crea una [cuenta gratuita en GitHub](https://github.com/join). Envía tu nombre de usuario de GitHub a tu editor/a, quien te dará acceso al sitio de envíos. Si bien no serás tú quien haga la carga inicial, necesitarás acceso para el proceso de revisión.
+2. **Prepara los materiales**: si tu traducción incluye imágenes adicionales a las que tenía originalmente la lección, asegúrate que todos los archivos están nombrados según las convenciones explicadas más arriba. Las imágenes debes enviarlas en una sola carpeta comprimida. Si tu lección incluye archivos de datos traducidos, estos deben ser enviados en otra carpeta comprimida.
+3. **Envía un correo electrónico a tu editor/a**: hazle saber a tu editor/a que tienes todo listo para el envío de tu lección. Este correo electrónico debe incluir el archivo .md de la lección y las carpetas comprimidas con las imágenes y datos, si corresponde.
+4. **Únete a la conversación**: tu editor/a subirá los archivos a nuestro [repositorio de envíos](https://github.com/programminghistorian/ph-submissions) y hará algunos cambios iniciales para asegurarse de que todo funciona bien. Además, abrirá un "ticket de revisión" para tu lección en la sección de *[issues](https://github.com/programminghistorian/ph-submissions/issues)* de ese repositorio.
+5. **Realiza las revisiones**: si bien la carga inicial de tu lección en el repositorio `ph-submissions` será realizada por tu editor/a, el proceso editorial requerirá que hagas modificaciones. Todas las ediciones posteriores deben ser hechas directamente por ti en ese repositorio para asegurarnos de que estás trabajando en la última versión del archivo.
+
+## El proceso de revisión de pares
+
+Tu editor comprobará que tus archivos se hayan cargado y formateado correctamente. En esta etapa se te enviará un enlace de vista previa donde se evidenciará cualquier error de formato para que puedas corregirlo. Las modificaciones debes hacerla en el archivo .md de tu traducción, que se encuentra en el [repositorio de propuesta de lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/traducciones).
+
+La revisión de pares se registrará en un ["ticket"](https://github.com/programminghistorian/ph-submissions/issues) que actúa como una discusión abierta en el tablero de mensajes. Ten en cuenta que nuestra revisión de pares se realiza en público y se mantiene a disposición del público como un registro permanente. Si tienes alguna preocupación o deseas solicitar una revisión cerrada, ponte en contacto con tu editor/a.
+
+El proceso de revisión por pares normalmente se realiza en tres etapas:
+
+1) Tu editor/a leerá y probará cuidadosamente tu traducción, proporcionando una primera ronda de retroalimentación a la que se te pedirá que respondas. El propósito de esta primera ronda de retroalimentación es asegurarse de que tu lección responde a las necesidades de la audiencia de *Programming Historian* y de que los revisores externos reciban una traducción que funcione. Normalmente se te dará un mes para responder a esta primera revisión.
+
+2) Tu editor/a abrirá la traducción para una revisión formal de pares. Esto incluirá al menos dos revisores que serán contactados por tu editor/a. La revisión también puede incluir comentarios de la comunidad más amplia, que son bienvenidos para contribuir con sus puntos de vista. Por lo general, tratamos de pedir a los revisores que aporten sus comentarios en el plazo de un mes, pero a veces circunstancias imprevistas hacen que esto no sea posible. Tu editor/a debe dejarte claro que no debes responder a las sugerencias de cambios hasta después de que se hayan publicado ambas revisiones y que el editor haya resumido y dado instrucciones claras para seguir adelante. En algunos casos esto puede ser una sugerencia para revisar sustancialmente o repensar la lección. En otros casos será cuestión de hacer algunos cambios menores. En función de los comentarios de la revisión de pares y de la naturaleza de las cuestiones planteadas, puede ser necesario revisar el tutorial más de una vez. En todo momento tu editor/a se esforzará porque tengas claros los pasos necesarios para que la lección sea publicable. Siempre tendrás la opción de retirarte del proceso de revisión si así lo deseas.
+
+3) Una vez que tu editor/a y revisores aprueben el texto, el editor recomendará la publicación a la jefa de redacción, quien leerá el tutorial para asegurarse de que cumpla con los lineamientos y estándares de esta Guía. En algunos casos, esta etapa puede considerar revisiones adicionales o edición de estilo para que el artículo se ajuste a nuestras normas de publicación. Si la jefa de redacción está satisfecha con tu lección, esta será trasladada al repositorio donde se aloja el sitio web de Programming Historian para su publicación. Tu editor/a te informará de cualquier información adicional que se requiera en esta etapa.
+
+Puede resultarte útil leer nuestra [Guía para editores](/es/guia-editor), donde se detalla nuestro proceso editorial.
+
+Si en algún momento tienes dudas de tu papel o de lo que debes hacer a continuación, publica una pregunta en el ticket de revisión de tu traducción. Nuestro equipo editorial responderá lo antes posible. Nos esforzamos por responder a todas las preguntas en unos pocos días.
+
+### Haznos responsables
+
+Nuestro equipo voluntario trabaja duro para proporcionar a traductores y traductoras una revisión entre pares rigurosa, colegiada y eficiente. Sin embargo, reconocemos que hay momentos en que las expectativas pueden no cumplirse. Queremos que quienes participan del proceso se sientan con el poder de exigirnos altos estándares. Si, por cualquier razón, sientes que recibiste un trato injusto, que el proceso se volvió confuso, que la revisión se ha retrasado innecesariamente, que recibiste un trato grosero por parte de los revisores, que tu editor/a no ha sido lo suficientemente receptivo/a o tienes cualquier otra inquietud, por favor, háznoslo saber para que podamos abordarlo de manera proactiva.
+
+Plantear una preocupación NO afectará negativamente el resultado de tu revisión de pares, incluso si se trata de una revisión de pares en curso.
+
+Para plantear una preocupación, por favor contacta a una de las siguientes personas, según te resulte más cómodo:
+
+* El/la editor/a de tu lección
+* La [jefa de redacción](/es/equipo-de-proyecto)
+* Nuestra ombudsperson independiente, [Silvia Gutiérrez de la Torre](/es/equipo-de-proyecto)
+
+Esperamos que no te encuentres en una situación incómoda, pero si esto sucede, te agradecemos que nos ayudes a mejorar.
+
+---
+
+La versión en inglés de esta guía de estilo fue creada con el apoyo de la Escuela de Humanidades de la Universidad de Hertfordshire. Esta traducción y adaptación al español es producto del trabajo conjunto del Equipo Editorial de Programming Historian en español.
diff --git a/es/plantilla-leccion.md b/es/plantilla-leccion.md
new file mode 100644
index 0000000000..775ef1f5e1
--- /dev/null
+++ b/es/plantilla-leccion.md
@@ -0,0 +1,86 @@
+# Plantilla para lecciones de Programming Historian en español
+
+Este archivo puede ser utilizado como plantilla para desarrollar tu lección. Contiene algunas indicaciones de formato que complementan **pero no remplazan** las orientaciones de la [Guía para autores](/es/guia-para-autores).
+
+# Metadatos de la lección
+
+**Borra todo lo que está hasta esta línea cuando envíes tu lección**
+
+title: |
+ EL TÍTULO DE LA LECCIÓN
+collection: lessons
+layout: lesson
+slug: DEJAR EN BLANCO
+date: DEJAR EN BLANCO
+translation_date: DEJAR EN BLANCO
+authors:
+- NOMBRE APELLIDO 1
+- NOMBRE APELLIDO 2, etc
+reviewers:
+- DEJAR EN BLANCO
+editors:
+- DEJAR EN BLANCO
+translator:
+- NOMBRE APELLIDO 1
+translation-editor:
+- DEJAR EN BLANCO
+translation-reviewer:
+- DEJAR EN BLANCO
+original: DEJAR EN BLANCO
+review-ticket: DEJAR EN BLANCO
+difficulty: DEJAR EN BLANCO
+activity: DEJAR EN BLANCO
+topics: DEJAR EN BLANCO
+abstract: DEJAR EN BLANCO
+doi: DEJAR EN BLANCO
+---
+
+# Contenidos
+
+Agrega la siguiente línea de código para incluir una tabla de contenidos en la lección:
+
+{% include toc.html %}
+
+--
+
+Algunos ejemplos de formato con Markdown:
+
+# Encabezado de primer nivel
+## Encabezado de segundo nivel
+### Encabezado de tercer nivel
+
+Dar formato en Markdown:
+*texto en cursiva*
+**texto en negrita**
+`código o nombres de archivos`
+
+### Enlaces
+Si quieres incluir enlaces a la página de Programming Historian (por ejemplo, para mencionar otras lecciones), debes utilizar enlaces relativos, es decir, no incluir la primera parte de la url: `programminghistorian.org`. Por ejemplo: [Análisis de corpus con Voyant Tools](/es/lecciones/analisis-voyant-tools)
+
+### Imágenes
+
+Bloque de código para insertar imágenes:
+
+{% raw %}
+``` markdown
+{% include figure.html filename="NOMBRE-ARCHIVO-IMAGEN" caption="PIE DE FOTO UTILIZANDO \"ESCAPED\" QUOTES" %}
+```
+{% endraw %}
+
+
+### Ejemplo de una tabla:
+
+| Encabezado 1 | Encabezado 2 | Encabezado 3 |
+| --------- | --------- | --------- |
+| Fila 1, columna 1 | Fila 1, columna 2 | Fila 1, columna 3|
+| Fila 2, columna 1 | Fila 2, columna 2 | Fila 2, columna 3|
+| Fila 3, columna 1 | Fila 3, columna 2 | Fila 3, columna 3|
+
+### Una nota a pie de página:
+
+Esto es un texto.[^1]
+Esto es más texto.[^2]
+
+# Notas
+[^1] Cita en formato Manual de Estilo Chicago
+[^2] Cita en formato Manual de Estilo Chicago
+