Merge pull request #1191 from eed3si9n/wip/copyedit

Fix some typos and grammatical mistakes

src/reference/guide/sbt-components.md

@@ -4,11 +4,11 @@ sbt components
 sbt runner
 ----------
 
-An sbt build is executed using the `sbt` runner, also called "sbt-the-shell-script" to distinguish from other components. Important thing to note is that sbt runner is designed to run **any version** of sbt.
+An sbt build is executed using the `sbt` runner, also called "sbt-the-shell-script" to distinguish from other components. It's important to note is that sbt runner is designed to run **any version** of sbt.
 
 ### Specifying sbt version with project/build.properties
 
-The sbt runner executes a subcomponent called sbt launcher, which reads `project/build.properties` to determine the sbt version for the build, and downloads the artifacts if needed:
+The sbt runner executes a subcomponent called sbt launcher, which reads `project/build.properties` to determine the sbt version for the build, and downloads the artifacts if they haven't been cached:
 
 ```
 sbt.version={{sbt_version}}
@@ -30,12 +30,12 @@ The sbt server is the actual build tool whose version is specified using `projec
 
 ### Coursier
 
-The sbt server runs [Couriser][coursier] as a subcomponent to resolve Scala libary, Scala compiler, and any other library dependencies your build needs.
+The sbt server runs [Couriser][coursier] as a subcomponent to resolve Scala library, Scala compiler, and any other library dependencies your build needs.
 
 ### Zinc
 
 Zinc is the incremental compiler for Scala, developed and maintained by sbt project.
-An often overlooked aspect of Zinc is that Zinc provides a stable API to invoke **any modern versions** of Scala compiler. Combined with the fact that Coursier can resolve any Scala versions, by installing the sbt runner, you can invoke any modern versions of Scala just by writing a single line `build.sbt`:
+An often overlooked aspect of Zinc is that Zinc provides a stable API to invoke **any modern versions** of Scala compiler. Combined with the fact that Coursier can resolve any Scala version, with sbt we can invoke any modern versions of Scala just by writing a single line `build.sbt`:
 
 ```scala
 scalaVersion := "{{scala3_example_version}}"
@@ -46,8 +46,8 @@ scalaVersion := "{{scala3_example_version}}"
 The sbt server supports [Build Server Protocol (BSP)](https://build-server-protocol.github.io/) to list build targets, build them, etc.
 This allows IDEs like IntelliJ and Metals to communicate with a running sbt server programmatically.
 
-Connecting with sbt server
---------------------------
+Connecting to sbt server
+------------------------
 
 Let's look at three ways of connecting to the sbt server.
 

src/reference/guide/why-sbt-exists.md

@@ -4,7 +4,7 @@ Why sbt exists
 Preliminaries
 -------------
 
-In Scala, a library or a executable programs used be compiled using the Scala compiler, `scalac`, or so it is documented in [Scala 3 Book](https://docs.scala-lang.org/scala3/book/taste-hello-world.html) at first:
+In Scala, a library or a program is compiled using the Scala compiler, `scalac`, as documented in the [Scala 3 Book](https://docs.scala-lang.org/scala3/book/taste-hello-world.html):
 
 ```scala
 @main def hello() = println("Hello, World!")
@@ -19,9 +19,9 @@ Hello, World!
 This process gets tedious and slow if we were to invoke `scalac` directly since we'd have to pass all the Scala source file names.
 
 Furthermore, most non-trivial programs will likely have library dependencies, and will therefore also depend transitively on their dependencies.
-This is doubly compilicated for Scala ecosystem because we have Scala 2.12, 2.13 ecosystem, Scala 3.x ecosystem, JVM, JS, and Native platforms.
+This is doubly complicated for Scala ecosystem because we have Scala 2.12, 2.13 ecosystem, Scala 3.x ecosystem, JVM, JS, and Native platforms.
 
-Rather than working with JAR files and `scalac`, we can avoid the manual toil by introducing a higher-level subproject abstraction and by using a build tool.
+Rather than working with JAR files and `scalac`, we can avoid manual toil by introducing a higher-level subproject abstraction and by using a build tool.
 
 sbt
 ---
@@ -32,20 +32,20 @@ It lets us declare subprojects and their various dependencies and custom tasks t
 To accomplish this goal, sbt does several things:
 
 - The version of sbt itself is tracked in `project/build.properties`.
-- Defines a domain-specific language (DSL) called **build.sbt DSL** that can declare Scala version and other subproject information in `build.sbt`.
+- Defines a domain-specific language (DSL) called **build.sbt DSL** that can declare the Scala version and other subproject information in `build.sbt`.
 - Uses Coursier to fetch subprojects dependencies and their dependencies.
 - Invokes Zinc to incrementally compile Scala and Java sources.
 - Automatically runs tasks in parallel whenever possible.
 - Defines conventions on how packages are published to Maven repositories to interoperate with the wider JVM ecosystem.
 
-To a large extent, sbt normalizes the commands needed to build a given program or library.
+To a large extent, sbt standardizes the commands needed to build a given program or library.
 
 Why build.sbt DSL?
 ------------------
 
 build.sbt DSL makes sbt a unique build tool,
 as opposed to other tools that use configuration file formats like YAML, TOML, and XML.
-Originally developed around 2010 ~ 2013, `build.sbt` can start almost like a YAML file, declaring just `scalaVersion` and `libraryDependencies`,
+Originally developed beween 2010 and 2013, `build.sbt` can start almost like a YAML file, declaring just `scalaVersion` and `libraryDependencies`,
 but it can supports more features to keep the build definition organized as the build grows larger:
 
 - To avoid repeating the same information, like the version number for a library, `build.sbt` can declare variables using `val`.