docs: improve consistency and fix typos

docs/contributing_docs.md

@@ -1,6 +1,6 @@
 # Contributing to documentation
 
-The testcontainers-go documentation is a static site built with [MkDocs](https://www.mkdocs.org/).
+The Testcontainers-go documentation is a static site built with [MkDocs](https://www.mkdocs.org/).
 We use the [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) theme, which offers a number of useful extensions to MkDocs.
 
 In addition we use a [custom plugin](https://github.com/rnorth/mkdocs-codeinclude-plugin) for inclusion of code snippets.

docs/features/build_from_dockerfile.md

@@ -40,7 +40,7 @@ req := ContainerRequest{
 ## Dynamic Build Context
 
 If you would like to send a build context that you created in code (maybe you have a dynamic Dockerfile), you can
-send the build context as an `io.Reader` since the Docker Daemon accepts is as a tar file, you can use the [tar](https://golang.org/pkg/archive/tar/) package to create your context.
+send the build context as an `io.Reader` since the Docker Daemon accepts it as a tar file, you can use the [tar](https://golang.org/pkg/archive/tar/) package to create your context.
 
 
 To do this you would use the `ContextArchive` attribute in the `FromDockerfile` struct.
@@ -58,5 +58,5 @@ fromDockerfile := testcontainers.FromDockerfile{
 }
 ```
 
-**Please Note** if you specify a `ContextArchive` this will cause testcontainers to ignore the path passed
-in to `Context`
+**Please Note** if you specify a `ContextArchive` this will cause Testcontainers-go to ignore the path passed
+in to `Context`.

docs/features/copy_file.md

@@ -17,7 +17,7 @@ nginxC, err := GenericContainer(ctx, GenericContainerRequest{
 nginxC.CopyFileToContainer(ctx, "./testresources/hello.sh", "/hello_copy.sh", 700)
 ```
 
-Or you can add a list of files in ContainerRequest's struct, which can be copied before the container started:
+Or you can add a list of files in the `ContainerRequest` initialization, which can be copied before the container starts:
 
 ```go
 ctx := context.Background()
@@ -45,7 +45,7 @@ It's also possible to copy an entire directory to a container, and that can happ
 
 It's important to notice that, when copying the directory to the container, the container path must exist in the Docker image. And this is a strong requirement for files to be copied _before_ the container is started, as we cannot create the full path at that time.
 
-Once we understood that, there are two ways to copy directories to a container. The first one is using the existing `CopyFileToContainer` method, which will internally check if the host path is a directory, internally calling the new `CopyDirToContainer` method if needed:
+There are two ways to copy directories to a container. The first way uses the existing `CopyFileToContainer` method, which will internally check if the host path is a directory, internally calling the new `CopyDirToContainer` method if needed:
 
 ```go
 ctx := context.Background()
@@ -79,7 +79,7 @@ if err != nil {
 }
 ```
 
-And the second way is using the `CopyDirToContainer` method which, as you probably know, needs the existence of the parent directory where to copy the directory:
+And the second way uses the `CopyDirToContainer` method which, as you probably know, needs the existence of the parent directory in order to copy the directory:
 
 ```go
 ctx := context.Background()

docs/features/docker_compose.md

@@ -7,7 +7,7 @@ This is intended to be useful on projects where Docker Compose is already used
 in dev or other environments to define services that an application may be
 dependent upon.
 
-You can override Testcontainers' default behaviour and make it use a
+You can override Testcontainers-go's default behaviour and make it use a
 docker-compose binary installed on the local machine. This will generally yield
 an experience that is closer to running docker-compose locally, with the caveat
 that Docker Compose needs to be present on dev and CI machines.
@@ -34,9 +34,9 @@ return nil
 ```
 
 Note that the environment variables in the `env` map will be applied, if
-possible, to the existing variables declared in the docker compose file.
+possible, to the existing variables declared in the Docker Compose file.
 
-In the following example, we demonstrate how to stop a Docker compose using the
+In the following example, we demonstrate how to stop a Docker Compose created project using the
 convenient `Down` method.
 
 ```go

docs/features/garbage_collector.md

@@ -13,7 +13,7 @@ Containers can be unused because:
 ## Terminate function
 
 As we saw previously there are at least two ways to remove unused containers.
-The primary method is to use the `Terminate(context.Conext)` function that is
+The primary method is to use the `Terminate(context.Context)` function that is
 available when a container is created. Use `defer` to ensure that it is called
 on test completion.
 
@@ -27,7 +27,7 @@ on test completion.
 
 [Ryuk](https://github.com/testcontainers/moby-ryuk) (also referred to as
 `Reaper` in this package) removes containers/networks/volumes created by
-Testcontainers-Go after a specified delay. It is a project developed by the
+Testcontainers-go after a specified delay. It is a project developed by the
 TestContainers organization and is used across the board for many of the
 different language implementations.
 
@@ -39,7 +39,7 @@ for more than 10 seconds, it will be killed.
 
 !!!tip
 
-    This feature can be disabled when creating a container
+    This feature can be disabled when creating a container.
 
 Even if you do not call Terminate, Ryuk ensures that the environment will be
 kept clean and even cleans itself when there is nothing left to do.

docs/features/using_podman.md

@@ -1,14 +1,14 @@
 # Using Podman instead of Docker
 
-Testcontainers supports to use Podman (rootless or rootful) instead of Docker.
+Testcontainers-go supports the use of Podman (rootless or rootful) instead of Docker.
 In most scenarios no special setup is required.
-Testcontainers will automatically discover the socket based on the `DOCKER_HOST` or the `TC_HOST` environment variables.
-Alternatively you can also configure the host with a `.testcontainers.properties` file.
+Testcontainers-go will automatically discover the socket based on the `DOCKER_HOST` or the `TC_HOST` environment variables.
+Alternatively you can configure the host with a `.testcontainers.properties` file.
 The discovered Docker host is also taken into account when starting a reaper container.
 
 There's currently only one special case where additional configuration is necessary: complex container network scenarios.
 
-By default Testcontainers takes advantage of the default network settings both Docker and Podman are applying to newly created containers.
+By default Testcontainers-go takes advantage of the default network settings both Docker and Podman are applying to newly created containers.
 It only intervenes in scenarios where a `ContainerRequest` specifies networks and does not include the default network of the current container provider.
 Unfortunately the default network for Docker is called _bridge_ where the default network in Podman is called _podman_.
 It is not even possible to create a network called _bridge_ with Podman as Podman does not allow creating a network with the same name as an already existing network mode.

docs/index.md

@@ -1,10 +1,10 @@
-# Testcontainers-Go
+# Testcontainers-go
 
 ![Testcontainers logo](./logo.png)
 
 ## About
 
-Testcontainers-Go is a Go package that makes it simple to create and clean up container-based dependencies for
+Testcontainers-go is a Go package that makes it simple to create and clean up container-based dependencies for
 automated integration/smoke tests. The clean, easy-to-use API enables developers to programmatically define containers
 that should be run as part of a test and clean up those resources when the test is done.