fix: fixing errors in documentation (#2728)

Co-authored-by: Louis-Maxime Crédeville <louis-maxime.credeville@gleamer.ai>

platform/docs/docs/deployment/build-for-production.md

@@ -69,7 +69,7 @@ directory. Our build process knows which configuration file to use based on the
 and registered extension's features, are configured using this file.
 
 The easiest way to apply your own configuration is to modify the `default.js`
-file. For more advanced cofiguration options, check out our
+file. For more advanced configuration options, check out our
 [configuration essentials guide](../configuration/index.md).
 
 ## Next Steps

platform/docs/docs/deployment/index.md

@@ -112,7 +112,7 @@ There are two important steps to making sure this setup works:
 
 1. Your Image Archive needs to be exposed, in some way, to the open web. This
    can be directly, or through a `reverse proxy`, but the Viewer needs _some
-   way_ to request it's data.
+   way_ to request its data.
 2. \* Your Image Archive needs to have appropriate CORS (Cross-Origin Resource
    Sharing) Headers
 
@@ -224,7 +224,7 @@ More info on this JSON format can be found here
 
 _CORS Issues (Cross-Origin Resource Sharing)_
 
-If you host a JSON API or Images on a different domain from the the app itself,
+If you host a JSON API or Images on a different domain from the app itself,
 you will likely have CORS issues. This will also happen when testing from
 Localhost and reaching out to remote servers. Even if the domain is the same,
 different ports, subdomains or protocols (https vs http) will also cause CORS
@@ -233,7 +233,7 @@ to allow your App server origin.
 
 For example:
 
-Lets assume your application is hosted on `https://my-ohif-server.com`.
+Let's assume your application is hosted on `https://my-ohif-server.com`.
 
 Your JSON API is hosted on `https://my-json-api.aws.com`
 

platform/docs/docs/deployment/nginx--image-archive.md

@@ -9,7 +9,7 @@ sidebar_position: 4
 
 At a certain point, you may want others to have access to your instance of the
 OHIF Viewer and its medical imaging data. This post covers one of many potential
-setups that accomplish that. Please note, noticably absent is user account
+setups that accomplish that. Please note, noticeably absent is user account
 control.
 
 Do not use this recipe to host sensitive medical data on the open web. Depending
@@ -22,12 +22,12 @@ that builds on the lessons learned here.
 
 Our two biggest hurdles when hosting our image archive and web client are:
 
-- Risks related to exposing our PACS to the netowrk
+- Risks related to exposing our PACS to the network
 - Cross-Origin Resource Sharing (CORS) requests
 
 ### Handling Web Requests
 
-We mittigate our first issue by allowing [Nginx][nginx] to handle incoming web
+We mitigate our first issue by allowing [Nginx][nginx] to handle incoming web
 requests. Nginx is open source software for web serving, reverse proxying,
 caching, and more. It's designed for maximum performance and stability --
 allowing us to more reliably serve content than Orthanc's built-in server can.
@@ -199,7 +199,7 @@ Here are some resources, specific to this setup, that may be helpful:
 - [lua-resty-auto-ssl](https://github.com/GUI/lua-resty-auto-ssl)
 - [Let's Encrypt + Nginx](https://www.nginx.com/blog/using-free-ssltls-certificates-from-lets-encrypt-with-nginx/)
 
-While we terminate SSL at Nginx, it may be worth using self signed certificates
+While we terminate SSL at Nginx, it may be worth using self-signed certificates
 for communication between services.
 
 - [SSL Termination for TCP Upstream Servers](https://docs.nginx.com/nginx/admin-guide/security-controls/terminating-ssl-tcp/)

platform/docs/docs/deployment/static-assets.md

@@ -16,7 +16,7 @@ less product offerings.
 While not required, it can simplify things to host your Web Viewer alongside
 your image archive. Services with more robust product offerings, like
 `Google Cloud`, `Microsoft's Azure`, and `Amazon Web Services (AWS)`, are able
-to accomodate this setup.
+to accommodate this setup.
 
 _Drag-n-drop_
 
@@ -111,7 +111,7 @@ Learn more about [surge.sh on their website](https://surge.sh/)
 > Websites for you and your projects. Hosted directly from your GitHub
 > repository. Just edit, push, and your changes are live.
 
-This deploy strategy makes more sense if you intend to maintain your project in
+This deployment strategy makes more sense if you intend to maintain your project in
 a GitHub repository. It allows you to specify a `branch` or `folder` as the
 target for a GitHub Page's website. As you push code changes, the hosted content
 updates to reflect those changes.
@@ -140,7 +140,7 @@ avoid using a proxy or to simplify authentication.
 If that is the case, check out some of our more advanced `docker` deployments
 that target these providers from the left-hand sidepanel.
 
-These guides can be a bit longer and a update more frequently. To provide
+These guides can be a bit longer and an update more frequently. To provide
 accurate documentation, we will link to each provider's own recommended steps:
 
 ### AWS S3 + Cloudfront