Hopefully, the last typos of this round. (#3817)

Author: BethanyG

concepts/bitwise-operators/about.md

@@ -117,7 +117,7 @@ This means that all bits are inverted and a number is _**interpreted as negative
 Positive numbers have an MSB of `0`.
 This representation has the advantage of only having one version of zero, so that the programmer doesn't have to manage `-0` and `+0`.
 
-This way of representing negative and positive numbers adds a complication for Python: there are no finite-integer concepts like `int32` or `int64` internally in the core langauge.
+This way of representing negative and positive numbers adds a complication for Python: there are no finite-integer concepts like `int32` or `int64` internally in the core language.
 In 'modern' Python, `int`s are of unlimited size (_limited only by hardware capacity_), and a negative or bit-inverted number has a (_theoretically_) infinite number of `1`'s to the left, just as a positive number has unlimited `0`'s.
 
 This makes it difficult to give a useful example of `bitwise not`:

exercises/practice/bob/.approaches/introduction.md

@@ -13,7 +13,7 @@ Regardless of the approach used, some things you could look out for include
 
 - Use the [`endswith`][endswith] method instead of checking the last character by index for `?`.
 
-- Don't copy/paste the logic for determining a shout and for determing a question into determing a shouted question.
+- Don't copy/paste the logic for determining a shout and for determining a question into determining a shouted question.
   Combine the two determinations instead of copying them.
   Not duplicating the code will keep the code [DRY][dry].
 

exercises/practice/nth-prime/.approaches/generator-fun/content.md

@@ -19,11 +19,13 @@ Using a lambda expression, we `filter` out any numbers above two that are prime.
 Doesn't this result in an infinite loop? 
 No - `filter` _also_ returns a generator object (which are [evaluated lazily][generator]), so while it's too will produce values infinitely if evaluated, it doesn't hang to program at the time of instantiation.
 
-`itertools.islice` takes in a generator object and an end count, returning a generator object which _only evalutes until that end count_. 
+`itertools.islice` takes in a generator object and an end count, returning a generator object which _only evaluates until that end count_.
 
 The next line exhausts all the values in the generator except the end, and we finally return the last element.
 
-We can utilize the `functools.cache` decorator for greater speeds at higher values of `number`, so we take it out. The added bonus is that a very long line of code is cleant up.
+We can utilize the `functools.cache` decorator for greater speeds at higher values of `number`, so we take it out.
+The added bonus is that a very long line of code is cleaned up.
+
 
 ```python
 from itertools import islice, count

exercises/practice/roman-numerals/.approaches/introduction.md

@@ -186,11 +186,11 @@ As the textbooks say, further analysis of this approach is left as an exercise f
 ## Which approach to use?
 
 In production, it would make sense to use the `roman` package.
-It is debugged and supports Roman-to-Arabic conversions in addtion to the Arabic-to-Roman approaches discussed here.
+It is debugged and supports Roman-to-Arabic conversions in addition to the Arabic-to-Roman approaches discussed here.
 
 Most submissions, like the `roman` package implementation, use some variant of [`loop-over-romans`][loop-over-romans].
 
-Using a [2-D lookup table][table-lookup] takes a bit more initialization, but then everthing can be done in a list comprehension instead of nested loops.
+Using a [2-D lookup table][table-lookup] takes a bit more initialization, but then everything can be done in a list comprehension instead of nested loops.
 Python is relatively unusual in supporting both tuples-of-tuples and relatively fast list comprehensions, so the approach seems a good fit for this language.
 
 No performance article is currently included for this exercise.