Grammar and wording

_tour/annotations.md

@@ -146,7 +146,7 @@ public class MyJavaClass extends TheirClass ...
 {% endtab %}
 {% endtabs %}
 
-An annotation application in Scala looks like a constructor invocation, for instantiating a Java annotation one has to use named arguments:
+An annotation application in Scala looks like a constructor invocation, but to instantiate a Java annotation one has to use named arguments:
 
 {% tabs annotations_7 %}
 {% tab 'Scala 2 and 3' for=annotations_7 %}

_tour/higher-order-functions.md

@@ -16,7 +16,7 @@ The terminology can get a bit confusing at this point, and we use the phrase
 "higher order function" for both methods and functions that take functions as parameters
 or that return a function.
 
-In a pure Object Oriented world a good practice is to avoid exposing methods parameterized with functions that might leak object's internal state. Leaking internal state might break the invariants of the object itself thus violating encapsulation.
+In a pure Object Oriented world, a good practice is to avoid exposing methods parameterised with functions that might leak an object's internal state. Leaking internal state might break the invariants of the object itself, thus violating encapsulation.
 
 One of the most common examples is the higher-order
 function `map` which is available for collections in Scala.
@@ -51,7 +51,7 @@ val newSalaries = salaries.map(x => x * 2) // List(40000, 140000, 80000)
 {% endtabs %}
 
 Notice how `x` is not declared as an Int in the above example. That's because the
-compiler can infer the type based on the type of function map expects (see [Currying](/tour/multiple-parameter-lists.html)). An even more idiomatic way to write the same piece of code would be:
+compiler can infer the type based on the type of function `map` expects (see [Currying](/tour/multiple-parameter-lists.html)). An even more idiomatic way to write the same piece of code would be:
 
 {% tabs map_example_3 %}
 
@@ -187,7 +187,7 @@ object SalaryRaiser:
 The new method, `promotion`, takes the salaries plus a function of type `Double => Double`
 (i.e. a function that takes a Double and returns a Double) and returns the product.
 
-Methods and functions usually express behaviours or data transformations, therefore having functions that compose based on other functions can help building generic mechanisms. Those generic operations defer to lock down the entire operation behaviour giving clients a way to control or further customize parts of the operation itself.
+Methods and functions usually express behaviours or data transformations. Therefore, having functions that compose based on other functions can allow us to build more generic mechanisms. Such generic operations avoid completely locking down their behaviour in order to give clients a way to control or further customize parts of those operations.
 
 ## Functions that return functions
 

_tour/package-objects.md

@@ -33,7 +33,7 @@ methods and variables.
 
 Any definitions placed at the top level of a package are considered members of the package itself.
 
-> In Scala 2 top-level method, type and variable definitions had to be wrapped in a **package object**.
+> In Scala 2, top-level method, type and variable definitions had to be wrapped in a **package object**.
 > These are still usable in Scala 3 for backwards compatibility. You can see how they work by switching tabs.
 
 {% endtab %}

_tour/tour-of-scala.md

@@ -28,7 +28,7 @@ Scala is a modern multi-paradigm programming language designed to express common
 Scala is a pure object-oriented language in the sense that [every value is an object](unified-types.html). Types and behaviors of objects are described by [classes](classes.html) and [traits](traits.html). Classes can be extended by subclassing, and by using a flexible [mixin-based composition](mixin-class-composition.html) mechanism as a clean replacement for multiple inheritance.
 
 ## Scala is functional ##
-Scala is also a functional language in the sense that [every function is a value](unified-types.html). Scala provides a [lightweight syntax](basics.html#functions) for defining anonymous functions, it supports [higher-order functions](higher-order-functions.html), it allows functions to be [nested](nested-functions.html), and it supports [currying](multiple-parameter-lists.html). Scala's [case classes](case-classes.html) and its built-in support for [pattern matching](pattern-matching.html) provide the functionality of algebraic types, which are used in many functional languages. [Singleton objects](singleton-objects.html) provide a convenient way to group functions that aren't members of a class.
+Scala is also a functional language in the sense that [every function is a value](unified-types.html). Scala provides a [lightweight syntax](basics.html#functions) for defining anonymous functions, supports [higher-order functions](higher-order-functions.html), allows functions to be [nested](nested-functions.html), and supports [currying](multiple-parameter-lists.html). Scala's [case classes](case-classes.html) and its built-in support for [pattern matching](pattern-matching.html) provide the functionality of algebraic types, which are used in many functional languages. [Singleton objects](singleton-objects.html) provide a convenient way to group functions that aren't members of a class.
 
 Furthermore, Scala's notion of pattern matching naturally extends to the [processing of XML data](https://github.com/scala/scala-xml/wiki/XML-Processing) with the help of [right-ignoring sequence patterns](regular-expression-patterns.html), by way of general extension via [extractor objects](extractor-objects.html). In this context, [for comprehensions](for-comprehensions.html) are useful for formulating queries. These features make Scala ideal for developing applications like web services.
 

_tour/variances.md

@@ -112,7 +112,7 @@ From this, we have to conclude that `Box[Cat]` and `Box[Animal]` can't have a su
 
 The problem we ran in to above, is that because we could put a Dog in an Animal Box, a Cat Box can't be an Animal Box.
 
-But what if we couldn't put a Dog in the box? Then we could just get our Cat back out and that's not a problem, so than it could follow the subtyping relationship. It turns out, that's indeed something we can do.
+But what if we couldn't put a Dog in the box? Then, we could just get our Cat back out without a problem, and it would adhere to the subtyping relationship. It turns out that that's possible to do.
 
 {% tabs covariance_1 class=tabs-scala-version %}
 {% tab 'Scala 2' for=covariance_1 %}