diff --git a/es/guia-para-autores-en-proceso b/es/guia-para-autores-en-proceso new file mode 100644 index 0000000000..977583a1f2 --- /dev/null +++ b/es/guia-para-autores-en-proceso @@ -0,0 +1,339 @@ +--- +title: Guía para autores y traductores +layout: blank +redirect_from: + - /new-lesson-workflow + - /author-guidelines +skip_validation: true +--- + +# Guía para autores + + +

Paso 1: Proponer o traducir un tutorial nuevo

+

Paso 2: Escribir y dar formato a un nuevo tutorial

+

Paso 3: Enviar un nuevo tutorial o traducción

+ + +Estas directrices han sido desarrolladas para ayudar a entender el proceso de creación de un tutorial para *Programming Historian*. Incluyen detalles prácticos y filosóficos sobre el proceso de redacción del tutorial, así como indicaciones sobre el flujo de trabajo y del proceso de revisión de pares. Si en algún momento no está claro, por favor envíe un correo electrónico al editor jefe {% include managing-editor.html lang=page.lang %}. + +## Paso 1: Proponer of traducir un nuevo tutorial + +
+Recibimos tutoriales pertinentes a las humanidades, que se centren en 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 deben ser adecuados a la complejidad de la tarea. Los tutoriales no deben exceder las 8.000 palabras (incluido el código). Las lecciones más cortas son bienvenidas. Es posible que las lecciones más largas deban dividirse en múltiples tutoriales. + +
+ +Si tienes una idea para una nueva lección, completa una el [formato de propuestas](/assets/forms/Lesson.Query.Form.txt) y envíalo a {% include managing-editor.html lang=page.lang %}. + +Puedes darte una idea de lo que publicamos revisando nuestros [tutoriales publicados]({{site.baseurl}}/es/lecciones), leyendo nuestra [guía para revisores]({{site.baseurl}}/es/guia-para-revisores) u ojeando [los tutoriales en desarrollo](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones). + +Si su propuesta es aceptada, un editor creará una página de "Propuesta" en nuestro [sitio de envíos](https://github.com/programminghistorian/ph-submissions/issues) con el título de la lección y los resultados de aprendizaje propuestos. Esto sirve para señalar el trabajo en curso. Para asegurar la publicación oportuna, los autores deben presentar su proyecto de artículo en un plazo de 90 días. + +Durante este período de 90 días, su punto de contacto será el jefe de redacción o un editor delegado según pa prerrogativa del jefe de redacción. + +## Paso 2: Escribir y formatear el tutorial +Esta guía de estilo establece un conjunto de normas para que los autores las utilicen al crear o traducir las lecciones en español para *Programming Historian*. Al usarla, nos ayudas a asegurar que el contenido sea consistente y accesible. + +Se presenta en tres secciones que deben ser leídas antes y después de la escritura: + +* A. Estilo y audiencia +* B. Directrices de estilo específicas +* 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 cuando planifiques tu lección. Vuelve a leerla antes de enviarla para asegurarte de que el tutorial cumple con estos requisitos. + +### 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 (tú). +* Procura escribir de un modo comprensible para hablantes de español de distintos lugares. +* 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 aceptada la 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 +Los lectores de *Programming Historian* viven en todo el mundo. Los autores pueden y deben tomar medidas para escribir su lección de forma accesible para el mayor número de personas posible. Siga estas directrices de cara a una audiencia global: + +* Escribe para alguien que no viva en tu país o que no comparta 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. +* **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). Los enlaces a [Wikipedia](https://es.wikipedia.org/) deben ser usados todo lo que sea necesario. Tén en cuenta 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 dialecto, o un lenguaje más difícil de lo necesario. +* **Geografía**: cuando hagas referencia a los lugares, sé específico. ¿"Noroeste" significa Brasil? ¿India? ¿África? Escribe siempre el nombre completo del área la primera vez que la utilices. +* **Multilingüísmo**: al elegir los métodos o instrumentos, tén en cuenta a los lectores 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 intelectualmente sólidos cuando se utilizan en textos en inglés. Cuando sea posible, elije enfoques que tengan documentación multilingüe o proporciona referencias multilingües para su lectura posterior. Esto ayudará a nuestros traductores. +* **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 "un asiático". Tén en cuenta que los términos pueden entenderse de manera diferente en los distintos países y que lo que haz 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, los lectores del Reino Unido entenderán el término "asiático" (India, Pakistán, Bangladesh) de manera diferente a los 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 cómo se presentarán a una audiencia global. + +### Escritura sostenible +*Programming Historian* publica lecciones pensando en 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, 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. Las interfaces cambian con frecuencia y los futuros lectores pueden confundirse. 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.2, o cualquier versión estará bien? + * **Refiérete a la documentación**: indica a los lectores documentación fiable cuando sea posible. Proporciona una guía general sobre cómo encontrar la documentación si es probable que haya nuevas versiones en el futuro. + * **Copias de datos**: todos los datos utilizados en las lecciones deben ser publicados con la lección 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. + +Los autores deben consultar 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 tratan cuestiones más específicas del estilo de escritura, como qué palabras utilizar, cómo usar la puntuación o qué formato utilizar para las fechas o los 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 "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"). + * Comprima las secuencias de fecha así; 1816-17, 1856-9, 1854-64. + * Para fechas escritas en forma numérica utilice el formato DD-MM-AA, which conforms to the standard ISO 8601:2004. This avoids ambiguity. + * Utilice BCE/CE not BC/AD for dates (eg 325BCE). [Asi aparece en la RAE: a. de J. C., a. de C., a. J. C. o a. C. (‘antes de (Jesu)Cristo’) y d. de J. C., d. de C., d. J. C. o d. C. (‘después de (Jesu)Cristo’): 211 a. C., 123 d. C. ] + * 1am, 6:30pm. Not 10 o’clock. [Algunos lineamientos de la RAE: La hora puede expresarse en letras o en números. El modelo de doce horas es el más utilizado cuando la hora se escribe con letras, y el más común en textos literarios y periodísticos. También puede usarse este sistema si se opta por escribir la hora con cifras; pero, en ese caso, : No es recomendable mezclar letras y números; así, es preferible escribir las diez de la noche que las 10 de la noche. para evitar ambigüedades, deben emplearse, tras los números, las abreviaturas a. m. y p.m.] + +### Números [revisar lineamientos de la RAE y de autoridades de la lengua en Latinoamerica] + * Spell out from one to nine; integers above 10. + * Use a consistent format if the boundary outlined above is crossed within a single sentence (five apples and one hundred oranges; 5 apples and 110 oranges). + * Use commas (not periods/full stops) between groups of three digits in large numbers (32,904 not 32904). Exceptions: page numbers, addresses, in quotation, etc. + * Use numerals for versions (version 5 or v.5) or actual values (eg, 5%, 7″, $6.00). + * Always use the symbol % with numerals rather than the spelled-out word (percent), and make sure it is closed up to number: 0.05%. + * Use [LaTeX formatting for mathematical formulae](https://davidhamann.de/2017/06/12/latex-cheat-sheet/). + * For units of measure, use metric or imperial but be consistent. + +### Encabezados +Los encabezados no deben contener un código de fuente o un formato de estilo como negrita, cursiva o código de fuente. +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. + +NO tiene estilo: + +* Acá hay un ítem y +* acá hay otro ítem; y +* acá hay un ítem final. + +Estilo: + +* Acá hay un ítem +* Acá hay otro ítem +* Acá está el último ítem + +[AGREGAR ALGO SOBRE CONSISTENCIA GRAMATICAL DE LOS ELEMENTOS ENUMERADOS] + +### Puntuación + * **Abreviaturas**: [revisar lineamientos de la RAE: https://www.rae.es/dpd/abreviatura] spell out all words on first mention. European Union (EU) and then EU. Do not use full points / periods or spaces between initials: BBC, PhD, mph, 4am, etc. + * **Corchetes / Paréntesis**: REVISAR LINEAMIENTOS PARA EL ESPAÑOL it is better to use commas or dashes. Use round brackets to introduce explanatory material into a direct quote, eg: He said: "When finished it (the tunnel) will revolutionise travel" or "She said adiós (goodbye)". Place a full stop / period outside a closing bracket if the material inside is not a sentence (like this). (But an independent sentence takes the full stop before the closing bracket.) + * **Dos puntos**: se utilizan para introducir listas, tabulaciones, textos, como en:REVISAR LINEAMIENTOS EN ESPAÑOL + * 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. + * Usar después del nombre de un orador para una frase entera citada: El Sr. James Sherwood, presidente de Sealink, dijo: "Tenemos..." + * La primera letra en minúscula después de dos puntos: así es como lo hacemos. + * **Coma**: NO EXISTE LA SERIA COMMA EN ESPAÑOL, REVISAR LINEAMIENTOS (this, that, and the other). + * **Guión**: a useful device to use instead of commas, but not more than one pair per sentence. + * **Ellipsis**: three periods separated from the preceding and following words by a space ( ... ). Use to condense a direct quote (thus the quote "the people sitting in this meeting room deserve a better deal" becomes "the people ... deserve a better deal"). + * **Exclamation Mark**: use only at the end of a direct quote when it is clear that the remark is exclamatory, eg "I hate intolerance!" + * **Full Stop / Period**: use frequently. Sentences should be short, crisp, straightforward. But do not put full stops between initials, after status title (Mx, Dr) or between abbreviations (EU). + * **Hyphen**: use to avoid ambiguity or to form a single idea from two or more words: + * Fractions: two-thirds. + * Most words that begin with anti, non and neo. + * A sum followed by the word worth - £10 million-worth of exports. + * Some titles (director-general, secretary-general, but Attorney General, general secretary etc). The rule is to adopt the usage of the authority which created it + * Avoiding ambiguity (little-used car ... little used car). + * Compass quarters (south-west, north-east). + * **Quotation Marks**: use straight (not curly) quotation marks for direct quotes. Use either single or double quotation marks but be consistent. + +### Mayúsculas +La pauta es usarlos con moderación en la prosa corriente. Reglas específicas: + +* **Títulos**: los encabezados y títulos de libros deben mayúscula en la primera letra del título: "Preparando los datos para el análisis"; *El orgullo y la pasión*, +* **Siempre en mayúscula**: + * **Nombre propios**: William J. Turkel – a menos que la persona elija deletrear su nombre de otra manera (por ejemplo "bell hooks"). + * **Organizaciones artísticas, culturales y gubernamentales, etc**: Museo de Arte Moderno, Casa de Cervantes, Biblioteca Nacional, Agencia Nacional de Tierras, Naciones Unidades. + * **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**: la primera letra en mayúscula para primera Guerra Mundial, Segunda Guerra Mundial; Guerra de Crimea/Boer/Vietnam/del Golfo; Guerra de los Cien Años. + * **Religión**: minúscula para anglicano, bautista, budista, católico, cristiano, hindú, metodista, musulmán, protestante, católico romano, sikh, y también para evangélicos, carismáticos, ateos. + * **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 (comonmente 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 France. El ministro de Hacienda. El Papa se escribe con mayúscula y la reina en minúscula. [REVISAR] + * **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"). + * **Instituciones religiosas, hospitales y escuelas**: cap up the proper or place name, lower case the rest eg Nurture Hillandale rehabilitation hospital, Vernon county primary school, Ali Pasha’s mosque. [REVISAR] +* **Siempre en minúscula**: + * **Committees, Reports and Inquiries**: committee on climate change, trade and industry committee, royal commission on electoral reform + * **Agencies, Commissions, Public Bodies, Quangos**: benefits agency, crown prosecution service, customs and excise, parole board + * **Estaciones**: spring, summer, autumn/fall, winter. + * **Tipos de cambio**: peso, sol, euro, franco, marco, dong, etc. + +### Referencias +* Los enlaces en lugar de las notas finales pueden ser apropiados en la mayoría de los casos. +* Asegúrate de que las frases vinculadas tengan un significado semántico. No enlace términos que son significativos solo para usuarios videntes como "haga clic aquí". +* Toda literatura publicada de manera tradicional y académica debe incluirse como notas al final, en lugar de ser enlazada. +* 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 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 + + +### Explicación de palabras difíciles [REVISAR CASOS ESPECÍFICOS PARA EL ESPAÑOL] + +[BORRÉ YA LOS QUE ESTABAN EN INGLÉS] + + + +## 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 directo 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-PROPUESTA-LECCION.md). HAY QUE ACTUALIZAR ESTA PLANTILLA PORQUE EN EL YAML FALTAN ALGUNOS CAMPOS + +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/) o [Notepad++](https://notepad-plus-plus.org/download). +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. +* AGREGAR NORMA RAE SOBRE USO DE CURSIVAS +* La cursiva se formatea utilizando *\*un asterisco\**. + +#### Subrayado + * No se utiliza. + +### Alertas y advertencias +Si quieres incluir un aparte o una advertencia a los lectores, puedes apartarlo del texto principal: + +``` +
+¡Asegúrate se seguir cuidadosamente las instrucciones! +
+``` + +### Figuras e imágenes +Las imágenes pueden ayudar a los lectores 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 sigioendo el patrón: LECCIÓN-NOMBRE1.jpg, LECCIÓN-NOMBRE2.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. + +Utiliza formatos de archivos amigables para la web como .png o .jpg y reduce las imágenes grandes a un máximo de 840px en el lado más largo. Esto es importante para los 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 asignado a tu lección puede ayudarle a subir sus imágenes cuando las envíes. + +Para insertar una imagen en su texto, utilice el siguiente formato: + +{% raw %} +``` markdown +{% include figure.html filename="NOMBRE-ARCHIVO-IMAGEN" caption="PIE DE FOTO UTILIZANDO \"ESCAPED\" QUOTES" %} +``` +{% 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 el editor se asegurará de que se reproduzcan correctamente cuando se publique la lección. + +### 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\`. + + +``` +Se verán así +``` +` y así `, respectivamente. + + +-- +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 de usuario**: 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 los lectores 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 estár 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 2: +`and`, `as`, `assert`, `break`, `class`, `continue`, `def`, `del`, `elif`, `else`, `except`, `exec`, `finally`, `for`, `from`, `global`, `if`, `import`, `in`, `is`, `lambda`, `not`, `or`, `pass`, `print`, `raise`, `return`, `try`, `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`. + + +## Paso 3: Enviando una nueva lección + +Comprueba que tu archivo con la lección ha sido preparado según las especificaciones anteriores. Una vez que estés satisfecho, te recomendamos encarecidamente que pidas al menos a dos personas que prueben tu tutorial y te den su opinión. Esto te ayudará a hacer mejoras que significan que nuestros compañeros de revisión pueden centrarse en ayudarte a producir la lección más sólida posible. + +Estás listo para someter la lección a la revisión de pares. Los envíos se hacen en nuestro sitio de revisión de pares en [Github](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones). + +1. **Obtener acceso**: crea una [cuenta gratuita en Github](https://github.com/join). Envía tu usuario de Github a tu editor quien te dará acceso para subir el tutorial al sitio de envíos. Déjale saber al editor el nombre del archivo y si tienes imágenes o archivos de datos que acompañen la lección. +3. **Cargar la lección**: una vez que su editor confirme que te ha dado acceso al sitio, sube su lección a la [carpeta de lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones). Si necesitas ayuda revisa las [instrucciones de GitHub](https://help.github.com/articles/adding-a-file-to-a-repository/). +4. **Cargar las imágenes**: si tu lección incluye imágenes, asegúrate de que todos los archivos se nombren de acuerdo con las convenciones de nomenclatura especificadas anteriormente. Su editor habrá creado una carpeta para que pueda subir sus imágenes en el [directorio de imágenes](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images). Esta carpeta debe tener el mismo nombre que el archivo de su lección. Suba sus imágenes a esta carpeta. Si no la ves, por favor contacta con tu editor y espera instrucciones. + +5. **Cargar los datos**: si su lección incluye archivos de datos éstos deberán cargarse en una carpeta con un nombre similar en el [directorio de "assets"](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/assets). +6. **Envía un correo electrónico a tu editor** para hacerle saber que has cargado tus archivos. + +## 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án los errores de formato y podrás corregirlos. + +La revisión de pares se registrará en un "[ticket de Github](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 de la revisión de pares. Si tienes alguna preocupación o deseas solicitar una revisión cerrada, póngase en contacto con el editor asignado. + +El proceso de revisión por pares normalmente se realiza en tres etapas: + +1) El editor asignado a tu lección leerá y probará cuidadosamente su 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 responda a las necesidades de los lectores de *Programming Historian*, y asegurarse de que los revisores externos reciban una lección que funcione. Normalmente se te dará un mes para responder a esta primera revisión. + +2) El editor abrirá la lección para una revisión formal de pares. Esto incluirá al menos dos revisores invitados por el editor, y 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. El editor debe dejarte claro que no debes responder a las reseñas hasta después de que se hayan publicado ambas reseñas y 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. 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, pero el editor se esforzará por garantizar que se le dé una vía clara para su publicación. Siempre tendrás la opción de retirarse del proceso de revisión si así lo deseas. + +3) Una vez que el editor y los revisores estén satisfechos con el artículo, el editor lrecomendará la publicación al Jefe de Redacción, quien leerá el tutorial para asegurarse de que cumpla con nuestras pautas y estándares de autor. En algunos casos puede haber revisiones adicionales o edición de textos en esta etapa para que el artículo se ajuste a nuestras normas de publicación. Si el Jefe de Redacción está satisfecho con el artículo será trasladado al sitio para su publicación. Tu editor te informará de cualquier información adicional que se requiera en esta etapa. + +Puede resultarte útil leer nuestras [guía para editores](es/guia-editor), donde se detalla nuestro proceso editorial. + +Si en algún momento no estás seguro de tu papel o de lo que debes hacer a continuación, publica una pregunta en el número de revisión de pares. Uno de nuestros editores responderá lo antes posible. Nos esforzamos por responder a todas las preguntas en unos pocos días. + +### Haznos responsables + +Nuestro equipo de voluntarios trabaja duro para proporcionar a los autores una revisión entre pares rigurosa, colegiada y eficiente. Sin embargo, reconocemos que hay momentos en que las expectativas pueden no cumplirse. Queremos que los autores se sientan con el poder de exigirnos altos estándares. Si, por cualquier razón, sientes que has sido tratado injustamente, que estás descontento o confundido por el proceso, que el proceso de revisión se ha retrasado innecesariamente, que un revisor ha sido grosero, que tu editor no ha sido lo suficientemente receptivo, o tienes cualquier otra inquietud, por favor, déjanos 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 editor de tu lección +* El jefe de redacción +* Nuestra ombudsperson independiente, [Silvia Gutiérrez de la Torre](/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/guia-traducciones.md b/guia-traducciones.md new file mode 100644 index 0000000000..04230bbebe --- /dev/null +++ b/guia-traducciones.md @@ -0,0 +1,72 @@ +--- +title: Guía para traductores +layout: blank +redirect_from: + - /new-lesson-workflow + - /guia-traducciones +skip_validation: true +--- + +# Guía para traductores + +

Paso 1: Proponer la traducción de una lección

+

Paso 2: Escribir y dar formato a una traducción

+

Paso 3: Enviar una lección traducida

+ +## Proponer la traducción de una lección +Si quieres traducir una lección publicada en *Programming Historian*, por favor mira la lista de traducciones pendientes y contacta con {% include managing-editor.html lang=page.lang %} para discutir tus habilidades lingüísticas y tu experiencia en la traducción. Buscamos traducciones que sean rigurosas, legibles y que consideren las necesidades de una audiencia que lea en español. + +Una vez que la traducción de una lección publicada es aprobada, uno de nuestros editores creará un "Ticket de Revisión de Traducción" en nuestro [repositorio Github](https://github.com/programminghistorian/ph-submissions) donde tendrá lugar la revisión por pares. Este ticket incluye una función de tablero de mensajes, que se utilizará para documentar el progreso realizado durante la revisión de la traducción. Para evitar retrasos en la publicación te pedimos que envíes tu traducción en un plazo de 90 días desde que el editor acepte tu propuesta. + +## Escribir y dar formato a una lección +Traducir una lección implica principalmente lo siguiente: +- traducir el cuerpo textual principal de una lección +- traducir los términos del código y los ejemplos, si es posible +- si una lección utiliza un software con una interfaz disponible en el idioma de la traducción, entonces los términos técnicos relacionados con el software que se utiliza en el texto (entradas de menú, botones, etc.) deben traducirse como corresponde +- traducir los títulos y subtítulos de las imágenes. En algunos casos, es necesario producir nuevas imágenes, por ejemplo, si un ejercicio utiliza un software con una interfaz que puede cambiarse al idioma de destino +- Adaptar los enlaces y notas proporcionados en el texto original para que se ajusten al contexto lingüístico al que se dirigen, si es posible; por ejemplo, el enlace a la documentación de los programas informáticos, las notas de Wikipedia, etc., si estos recursos se proporcionan en el idioma de destino. + +Si decides traducir, por favor ten en cuenta que te estás dirigiendo a una audiencia global. Para cuestiones de estilo y elección de idioma, por favor revisa nuestra [Guía para autores]({{site.baseurl}}/es/guia-para-autores). + +Todas nuestras lecciones deben ser escritas en Markdown y seguir nuestras directrices de formato técnico, también disponibles en nuestra [Guía para autores]({{site.baseurl}}/es/guia-para-autores). + + +## Enviar una lección traducida +Una vez que tu archivo de traducción ha sido preparado según las especificaciones anteriores, está listo para someterlo a una revisión de pares. + +Tenemos una [página de Programming Historian en GitHub](https://github.com/programminghistorian), donde mantenemos dos repositorios (un repositorio es un lugar para almacenar archivos y carpetas relacionadas - puedes pensar en ello como una especie de carpeta). Uno de ellos, llamado [jekyll], aloja el código de la versión en vivo del sitio que ves en http://programminghistorian.org. El otro repositorio se llama [ph-submissions]. + +Nuestra forma preferida para que los traductores envíen una lección es añadirlas directamente al repositorio [ph-submissions] (o repo, para abreviar). Gracias a las características de GitHub, puedes hacer esto usando acciones de arrastrar y soltar con las que probablemente ya estés familiarizado. Como nuevo traductor, estos son los pasos a seguir: + +1. Crea una [cuenta gratuita en GitHub](https://github.com/join). Esto tomará 30 segundos. +2. Envía un correo electrónico a tu editor con tu nuevo nombre de usuario de GitHub y el nombre del archivo de la lección. El editor te añadirá como **colaborador** en el repositorio [ph-submissions]. Una vez que seas añadido como colaborador, podrás hacer cambios directos en el repositorio [ph-submissions], incluyendo añadir, editar, eliminar y renombrar archivos. El editor también creará una carpeta con el mismo nombre de su lección en la carpeta de imágenes. (Si tienes otros archivos de datos a los que te conectas en tu tutorial, por favor pregunta a tu editor sobre ellos). +3. Una vez que tu editor te comunique que has sido agregado como colaborador, navega hasta la carpeta [es] y luego entra a la [carpeta lecciones](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/es/lecciones) del repositorio [ph-submissions]. A continuación, arrastra y suelta el archivo de anotaciones de tu lección desde tu ordenador a la ventana de tu navegador. (Si necesitas ayuda, revisa las instrucciones de [GitHub](https://help.github.com/articles/adding-a-file-to-a-repository/). Ahora haz clic en el botón verde "Commit Changes"; no necesitas cambiar el mensaje predeterminado. +4. Es posible que tengas algunas imágenes que acompañen a tu lección. Asegúrate de que todos los archivos de imágenes estén nombrados apropiadamente de acuerdo con nuestras convenciones de nomenclatura. Navega a la [carpeta de imágenes](https://github.com/programminghistorian/ph-submissions/tree/gh-pages/images) en el repositorio [ph-submissions]. Haga clic en la carpeta con el mismo nombre de su lección (que tu editor debería haber creado para ti; si no la ves, ponte en contacto con tu editor y espera las instrucciones). Una vez que estés en la carpeta correcta, arrastra y suelta todos los archivos de imágenes en la ventana del navegador, como en el paso 3. No puedes arrastrar una carpeta de imágenes; pero puedes arrastrar varios archivos a la vez. +5. ¡Previsualiza tu lección! Espera unos minutos (normalmente menos) para que GitHub convierta tu archivo Markdown en HTML y lo convierta en una página web en directo. Luego navega a `http://programminghistorian.github.io/ph-submissions/es/lecciones/` + `YOUR-LESSON-NAME` (pero reemplaza YOUR-LESSON-NAME con el nombre de tu archivo). +6. Hazle saber a tu editor que has subido los archivos de tu lección al repositorio de envíos ph (ellos deberían recibir una notificación sobre esto, pero queremos asegurarnos de que nada se pase por alto). + + +
+Si estás familiarizado con la línea de comandos git y GitHub, también puedes enviar tu traducción e imágenes como una solicitud de pull al repo `ph-submission` y fusionarlo tu mismo después de ser añadido como colaborador. + +### ¡Traducción eviada! ¿Ahora qué? +Para ver lo que sucede después de enviar una traducción, siéntete libre de navegar por nuestras [guía para editores](es/guia-editor), que detallan nuestro proceso editorial. Los puntos más destacados se encuentran a continuación: + +El paso inmediato más importante es que tu editor creará un [*issue*](https://github.com/programminghistorian/ph-submissions/issues) para la nueva traducción en el repositorio [ph-submissions], con un enlace a tu lección (que previsualizaste en el paso 5). El editor y al menos dos revisores invitados por el editor publicarán sus comentarios sobre este *issue*. + +### Espera la retroalimetación de los revisores +Nuestro objetivo es completar el proceso de revisión en cuatro semanas, pero a veces se producen retrasos o la gente está ocupada y el proceso puede tardar más de lo que esperábamos. + +De acuerdo con las ideas de la investigación pública y la revisión abierta de pares, animamos a que las discusiones se mantengan en GitHub. Sin embargo, también queremos que todos se sientan cómodos con el proceso. Si necesitas discutir algo en privado, por favor, no dudes en [enviar un correo electrónico a tu editor directamente](/equipo de proyecto), o en contactar con uno de nuestra [mediadora](silviaegt@gmail.com). + +### Responde a la retroalimentación +Su editor y revisores probablemente harán algunas sugerencias para mejorar el *issue* de su traducción. El editor debe aclarar qué sugerencias son esenciales de abordar, cuáles son opcionales y cuáles pueden ser dejadas de lado. + +Puedes editar tus archivos en GitHub, siguiendo [estas instrucciones](https://help.github.com/articles/editing-files-in-your-repository/). + +Tus revisiones deben completarse dentro de las cuatro semanas siguientes a la recepción de la orientación del editor sobre cómo responder a la revisión por pares. Esto es para asegurar que las traducciones se publiquen a tiempo y no se alarguen innecesariamente. Si prevés que tendrá problemas para cumplir con la fecha límite, debes ponerte en contacto con tu editor para establecer una fecha de entrega más adecuada. + +Si en algún momento no estás seguro de tu rol o de lo que debe hacer a continuación, no dudes en enviar un correo electrónico a tu editor o, mejor aún, en publicar una pregunta en el *issue* (otro editor podría verlo y podría ayudarte antes que tu propio editor). Comprenderás que a veces nos llevará unos días responder, pero esperamos que las mejoras de la lección terminada valgan la pena la espera. + +### Hazle saber a tu editor que has terminado +Una vez que hayas terminado de responder a los comentarios, avísale saber a tu editor. Si están satisfechos con la lección en esta etapa, el, Jefe de Redacción de *Programming Historian* revisará tu lección, la moverá del repositorio `ph-submissions` al repositorio `jekyll`, y actualizará nuestro directorio de lecciones donde será publicada.