Change:
5. En la siguiente pantalla, puedes añadir más detalles sobre tu PR, luego pincha en <kbd>Crear pull request</kbd>. <del> Enhorabuena 🎉! Acabas de crear una pull request. </del> <ins> Felicidades 🎉! Acabas de crear un pull request. </ins> #### Trabajar desde tu sistema local (_recomendado_ para revisar cambios) <del> No es obligatorio que trabajes en tu sistema personal, salvo que desees previsualizar tus cambios, o trabajar con mejoras y arreglos de UI. También es recomendable si tienes problemas con git como errores de integración, rebase, etc. </del> <ins> No es obligatorio que trabajes en tu sistema personal, salvo que desees pre-visualizar tus cambios, o trabajar con version actualizada y arreglos de UI. También es recomendable si tienes problemas con git como errores de integración, rebase, etc. </ins> <del> ##### Lee sobre esta recomendaciones en [Cómo configurar freeCodeCamp localmente](/docs/how-to-setup-freecodecamp-locally.md) </del> <ins> ##### Lee sobre estas recomendaciones en [Cómo configurar freeCodeCamp localmente](/docs/how-to-setup-freecodecamp-locally.md) </ins> ### Aceptación de la PR <del> Estas son algunos criterios utilizados por los revisores cuando evalúan PRs: </del> <ins> Estos son algunos criterios utilizados por los criticos cuando evalúan PRs: </ins> - Descripción y título relevantes - La PR respeta la [guía de estilo](/docs/style-guide-for-guide-articles) - Consejos generales de QA de las [recomendaciones para Moderadores](https://forum.freecodecamp.org/t/freecodecamp-moderator-guidelines/18295) <del> - Siempre y cuando la PR suponga una mejora o ampliación de la guía, será aceptada aunque tenga errores gramaticales o contenido parcial </del> <ins> - Siempre y cuando el PR suponga una mejora o ampliación de la guía, será aceptado aunque tenga errores gramaticos o contenido parcial </ins> - Las PR más antiguas se revisan primero #### Etiquetas - **contenido** es para Pull Requests que modifican el contenido de artículos en la guía (añaden un nuevo artículo o actualizan uno existente) <del> - **duplicada** es para Pull Request que contienen el mismo contenido que otra PR abierta - **cambios solicitados** es para Pull Requests que necesitan algún cambio antes de ser integradas - **pasada** es para Pull Requests que con etiqueta _"changes requested"_ que no han tenido actividad durante al menos 2 semanas y serán por tanto cerradas - Una  pull request _pasada_ debe cerrarse. </del> <ins> - **duplicada** es para Pull Request que contienen el mismo contenido que otro PR abierto - **cambios solicitados** es para Pull Requests que necesitan algún cambio antes de ser integrados - **pasada** es para Pull Requests que con etiqueta _"changes requested"_ que no han tenido actividad durante al menos 2 semanas y serán por tanto cerrados - Un  pull request _pasado_ debe cerrarse. </ins> - Este es [un ejemplo](https://github.com/freeCodeCamp/freeCodeCamp/pull/235). #### Contenido conflictivo/duplicado <del> Se considera **duplicada** una PR si hace cambios al mismo artículo que otra PR. </del> <ins> Se considera **duplicado** un PR si hace cambios al mismo artículo que otro PR. </ins> En general el revisor: <del> 1. Organizará las PR desde la más antigua </del> <ins> 1. Organizará los PR desde lo más antiguo </ins> 2. Buscará para PRs con contenido similar <del> 3. Integrará desde la más antigua a las más nueva </del> <ins> 3. Integrará desde lo más antiguo a los más nuevos </ins> <del> Muy probablemente aparecerán conflictos al integrar PRs duplicadas. </del> <ins> Muy probablemente aparecerán conflictos al integrar PRs duplicados. </ins> <del> Los revisores harán todos los esfuerzos posibles para resolver estos conflictos e integrar las PRs. </del> <ins> Los revisores harán todos los esfuerzos posibles para resolver estos conflictos e integrar los PRs. </ins> #### Solicitar cambios <del> Si la Pull Request no es perfect el revisor podría: </del> <ins> Si el Pull Request no es perfecto el revisor podría: </ins> - solicitar cambios al contribuidor y añadir la etiqueta *cambios solicitados* <del> - solucionar errores menores y hacer un envío encima de la PR </del> <ins> - solucionar errores menores y hacer un envío encima de el PR </ins> #### Travis CI Build <del> Todas las PRs deben superar los test de Travis CI antes de poder ser integradas. </del> <ins> Todos los PRs deben superar los test de Travis CI antes de poder ser integrados. </ins> <del> Si una PR rompe la ejecución (un test de Travis CI falla y muestra una "X" roja) hay tres cauas probables y tendrás que resolver el problemas antes de que podamos integrar la PR: </del> <ins> Si un PR rompe la ejecución (un test de Travis CI falla y muestra una "X" roja) hay tres causas probables y tendrás que resolver el problema antes de que podamos integrar el PR: </ins> <del> 1. Tu PR crea un nueva artículo pero la falta un archivo `index.md` en algún lugar. </del> <ins> 1. Tu PR crea un nuevo artículo pero le falta un archivo `index.md` en algún lugar. </ins> - Cada directorio en `src/pages` necesita un archivo `index.md` en él (y debe llamarse `index.md`). - Dos escenarios muy probables son - llamaste al archivo de forma distinta a `index.md`, o

Discussion:
from its english version at from its english version at from its english version at from its english version at from its english version at from its english version at  When you make a PR for this particular issue, do not tag it with instead just reference it with
Hey ! How could I claim so we don't double work? Thanks
Hi ! Actually we just merge in the first PR for open issues. And your comment on this thread is enough. So, its yours. Happy translating.
I just open a PR for
thanks a lot that was fast! Would you be interested in translating these in future as well? If yes, please keep a watch on this thread. We will be updating on the progress often Happy contributing.
Done translating ! My PR is available at ! Thanks for all you do, freeCodeCamp
I have sent a translation proposal for /docs/how-to-work-on-guide- PR Hope it will help!
There is still work pending on this. When you make a PR for this particular issue, do not tag it with instead just reference it with
Hello, I'm starting to help on the translation of the document /how-to-set-up-freecodecamp-
Working on /docs/spanish/how-to-work-on-guide-
Hello, I've improved the file
Hello, Improving docs/spanish/how-to-catch-outgoing-emails-
Hi, I'm improving docs/spanish/how-to-work-on-coding-
Hi, can I help with /docs/spanish/how-to-setup-freecodecamp-
Sorry, I opened a bad PR regarding but already closed it. I found there was still an English part to be translated
Hi! Is there any remaining documentation where I can help translate?
you can improve or fix redaction and spelling errors.
Hi there, It would be good if at the top are checked so we can see what is left to be translated. Thanks
Where I can start helping?
sorry to put it in this issue, but is there any way somebody could help with the pull requests? I mean, there are 5K+ opened already, people are sending them in troves, and I suspect a lot of them are a total crap (Like ) . I guess you opened a Pandora Box with your articule about HacktoberFest.

Hey all, not a translation, but fixes for the language bar of HTML links on the README file for Spanish, and markdown links to the How To guides that everyone has been translating. . or anyone else looking to do translations in Spanish, you could make a copy of the 2 style guides to translate into Spanish from the English version in the doc folder. It looks like those weren't in to the Spanish folder originally or included on this issue. Just leave the title the same, but put it in the Spanish folder
Hola! to all. I believe we should have guidelines for Spanish translations, which include what treatment (formal or informal) to use when referring to actions or the user. For example, Agregue (formal) or Agrega (informal). - I don't know if this kind of things are found in other languages. In the last articles I've read I've seen a mix between formal and informal, and I think we should standardize (I have done it with some articles). I propose to always use informal. Another thing that could be specified in the guidelines is: Challenges translations. Should they be translated? Referrals to types and attributes (which need to be in English for proper coding). For example, type "date" not type "fecha". If there is a guideline already, please let me know, if not, I would be happy to start one (just let me know where to put it). Hey I would like to know your thoughts about this. Thanks to you all and happy coding!
I agree that we should standardize around informal. I agree with you that we should look out for words like "fecha" that have been accidentally translated during our automated translation process.
Hi all I'm not sure if this is the right issue to discuss this, or if I should open a new one. I'm happy to open a new one if that makes things easier to track. I'll keep it here for the moment. What do people think about translating "array" as "arreglo"? I think this is a big mistake that has been repeated since somebody made that bad translation many years ago. As any Spanish speaker know, "arreglo" means "repair" (), and it makes any programming related text even harder to understand.

This is especially true for programming texts because it's full of abstract nouns and things that are not easy to represent in a tangible way. I learned to code in English (mainly FCC and Coursera), and after a while, I stumbled upon a programming text written in Spanish. I couldn't understand what it was talking about until I found out that "arreglo" was the (really bad) translation of "array". Then I could read the text as if I was reading an encoded message that had to be deciphered. I propose that the Spanish version of FreeCodeCamp doesn't carry on with that translation, which is just based on the similarity of the spelling but has nothing to do with the meaning of the words. I think the right term in Spanish is "ristra". According to the : Which basically means: "A group of things placed one after another" They also share all the phonems in "array", with the adittion of /r/ (rolling r) and /t/ in "ristra". I'm open to other candidates, but please, let's take "arreglo" out of the Spanish version. The word "array" has been used in Spanish texts before and even though it's not a Spanish word, I think it's still better than a word that exists with a different meaning. And to be honest, anyone learning how to code will have to become familiar with certain English terms like "list", "function", "import", "scope", etc. [1]: [2]:
Hello guy, I vote for yes, let’s do the change and I think will create a huge impact around of the world! Please let me know if you have more question questions or concerns. Andres Haro Cell: (619) 534-3190
Thanks - I agree that these machine translations need improvement. I encourage you to dig in and start fixing them. Be sure to join if you need help getting set up
There is still work pending on this. When you make a PR for this particular issue, do not tag it with instead just reference it with
Thanks for working on the translations for the "Contributing to freeCodeCamp". Here on we are making contributing to translations for contribution docs ad hoc. You are free to make pull-requests for improving these translations.

We are closing the issue as these do not need tracking per se. You can raise a fresh issue if you find something incorrect in the existing docs.