Corrected capitalization, corrected to American spellings and typos (#30685)

* Translate challenge subtitles and example challenge text to Spanish

* Corrected errors in syntax and punctuation

* Multiple corrections of it/s to its plus other grammar corrections

* Correction and added paragraph to CSS Flex article

* Corrected my own typo

* Corrected capitalization, American spellings and typos

guide/english/agile/continuous-integration/index.md

@@ -3,7 +3,7 @@ title: Continuous Integration
 ---
 ## Continuous Integration
 
-At it's most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote `master` branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potentiual build to regression test the new code, i.e. test that the new code does not break existing, working features.
+At its most basic, continuous integration (CI) is an agile development methodology in which developers regularly merge their code directly to the main source, usually a remote `master` branch. In order to ensure that no breaking changes are introduced, a full test suite is run on every potentiual build to regression test the new code, i.e. test that the new code does not break existing, working features.
 
 This approach requires good test coverage of the code base, meaning that a majority, if not all, of the code has tests which ensure its features are fully functional. Ideally continuous integration would be practiced together with full <a href='https://guide.freecodecamp.org/agile/test-driven-development' target='_blank' rel='nofollow'>Test-Driven Development</a>.
 

guide/english/agile/integration-hell/index.md

@@ -3,13 +3,13 @@ title: Integration Hell
 ---
 ## Integration Hell
 
-Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless sring of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.
+Integration Hell is a slang term for when all the members of a development team goes through the process of implementing their code at random times with no way to incorporate the different pieces of code into one seamless string of code. The development team will have to spend several hours or days testing and tweaking the code to get it all to work.
 
-In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures, and difficult integration. This painful integration work at the end of the project is the eponymous hell.
+In practice, the longer components are developed in isolation, the more the interfaces tend to diverge from what is expected. When the components are finally integrated at the end of the project, it would take a great deal more time than allocated, often leading to deadline pressures and difficult integration. This painful integration work at the end of the project is the eponymous hell.
 
-Continuous Integration, the idea that a development team should use specific tools to "continously integrate" the parts of the code they are working on multiple times a day so that the tools can match the different "chunks" of code together to integrate much more seamlessly than before.
+Continuous Integration is the idea that a development team should use specific tools to "continously integrate" the parts of the code they are working on multiple times a day so that the tools can match the different "chunks" of code together to integrate much more seamlessly than before.
 
-Code Repositories, like Git (and it's open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.
+Code Repositories, like Git (and its open source interface we all know and love, GitHub) allow development teams to organize their efforts so that more time can be spent coding and less time on worrying if the different parts of the code will all integrate.
 
 <a href='https://guide.freecodecamp.org/agile/continuous-integration/'>Continuous Integration</a> is the Agile antidote to this problem. Integration is still painful, but doing it at least daily keeps interfaces from diverging too much.
 

guide/english/agile/retrospectives/index.md

@@ -19,7 +19,7 @@ And from this discussion, the team creates a list of behaviors that they work on
 
 When commiting to action items, make sure you focus on 1 - 3. It is better to get a couple done, than commiting to more and not doing them. If it is difficult to come up with actions, try running experiments: Write down what you will do and what you want to achieve with that. In the following retro check if what you did achieved what you had planned. If it did not - you can learn out of the experiment and try out something else. 
 
-A good approach to find out which topics should be discussed is *"Discuss and mention"*. It consists on a board with as many columns as people in the team (you can use something like Trello or just a regular whiteboard) and two more for the things to "discuss" and those to be "mentioned". Everybody has 10 minutes to fill their column with things from the last sprint they want to highlight (these are represented with cards or Post-it's). Afterwards, each team member explains each of their own items. Finally, each team member chooses which topics they think should be mentioned or discussed, by moving the card/post-it to the respectively column. The team then decides which topics should be discussed and talk about them for about 10 minutes.
+A good approach to find out which topics should be discussed is *"Discuss and mention"*. It consists on a board with as many columns as people in the team (you can use something like Trello or just a regular whiteboard) and two more for the things to "discuss" and those to be "mentioned". Everybody has 10 minutes to fill their column with things from the last sprint they want to highlight (these are represented with cards or Post-its). Afterwards, each team member explains each of their own items. Finally, each team member chooses which topics they think should be mentioned or discussed, by moving the card/post-it to the respectively column. The team then decides which topics should be discussed and talk about them for about 10 minutes.
 
 Invite the scrum team only to the Retrospective. (Delivery Team, Product Owner, Scrum Master). Discourage managers, stakeholders, business partners, etc. They are a distraction and can hinder the sense of openness the team needs.