docs(spelling): Add codespell config + github action, run and fix a good number of typos (#3645)

2023-09-12 07:40:38 -04:00
1 parent 64079e0720
commit 11ca5b6eae
@@ -54,7 +54,7 @@ This package also stores Meteor components for the interactive lesion table used
 ### User (*ohif-user*)

 ### Basic Viewer Components (*ohif-viewerbase*)
-This is the largest package in the repository. It holds a large number of re-usable Meteor components that are used to build both the OHIF Viewer and Lesion Tracker.
+This is the largest package in the repository. It holds a large number of reusable Meteor components that are used to build both the OHIF Viewer and Lesion Tracker.

 ### WADO Proxy (*ohif-wadoproxy*)
 Proxy for CORS
@@ -5,4 +5,4 @@ At the time of project conception, Meteor was a simple way to begin using bleedi

 ## Do you have any plans to stop using Meteor?

-We have considered migrating templates from Blaze (http://blazejs.org/) to React (https://reactjs.org/) or Vue (https://vuejs.org/), simply because these decouple the view layer from the remainder of the application. Blaze currently lacks [Stand-alone Support](http://blazejs.org/#Better-Stand-alone-Support) which means that our templates are not re-usable outside of a Meteor application. This is certainly a downside, but the resource cost to migrate every template is significant.
+We have considered migrating templates from Blaze (http://blazejs.org/) to React (https://reactjs.org/) or Vue (https://vuejs.org/), simply because these decouple the view layer from the remainder of the application. Blaze currently lacks [Stand-alone Support](http://blazejs.org/#Better-Stand-alone-Support) which means that our templates are not reusable outside of a Meteor application. This is certainly a downside, but the resource cost to migrate every template is significant.
@@ -59,7 +59,7 @@ This diagram is a conceptual illustration of how the Viewer is architected.

 1. (optional) `extensions` can be registered with `@ohif/core`'s
   `ExtensionManager`
-2. `@ohif/core` provides bussiness logic and a way for `@ohif/viewer` to access
+2. `@ohif/core` provides business logic and a way for `@ohif/viewer` to access
   registered extensions
 3. The `@ohif/viewer` composes and provides data to components from our
   component library (`@ohif/ui`)
@@ -99,7 +99,7 @@ support it yet, but it is gaining wider adoption.

 If you have an existing archive and intend to host the OHIF Viewer at the same
 domain name as your archive, then connecting the two is as simple as following
-the steps layed out in our
+the steps laid out in our
 [Configuration Essentials Guide](./../configuring/index.md).

 #### What if I don't have an imaging archive?
@@ -273,7 +273,7 @@ You can find an example of this setup in our

 In general, we recommend using the "Authorization Code Flow" ( [see
 `response_type=code` here][code-flows]); however, the "Implicit Flow" ( [see
-`response_type=token` here][code-flows]) can work if additonal precautions are
+`response_type=token` here][code-flows]) can work if additional precautions are
 taken. If the flow you've chosen produces a JWT Token, it's validity can be used
 to secure access to your Image Archive as well.

@@ -75,7 +75,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](/configuring/index.md).

 ## Next Steps
@@ -8,7 +8,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
@@ -21,12 +21,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.
@@ -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_

@@ -77,7 +77,7 @@ _Create Your First User_
  - Email Verified: `ON`
  - Click `Save`
 - Click the `Credentials` Tab
-  - New Pasword: `test`
+  - New Password: `test`
  - Password Confirmation: `test`
  - Temporary: `OFF`
  - Click: `Reset Password`
@@ -1,10 +1,10 @@
 ---
 sidebar_position: 3
-title: Continous Integration
+title: Continuous Integration
 ---
-# Continous Integration (CI)
+# Continuous Integration (CI)

-This repository uses `CircleCI` and `Netlify` for continous integration.
+This repository uses `CircleCI` and `Netlify` for continuous integration.

 ## Deploy Previews

@@ -14,7 +14,7 @@ we make to the OHIF Viewer, then follow these steps:
 - [Fork][fork-a-repo] the [OHIF/Viewers][ohif-viewers-repo] repository
 - [Create a local clone][clone-a-repo] of your fork
  - `git clone https://github.com/YOUR-USERNAME/Viewers`
- Add OHIF/Viewers as a [remote repository][add-remote-repo] labled `upstream`
+- Add OHIF/Viewers as a [remote repository][add-remote-repo] labeled `upstream`
  - Navigate to the cloned project's directory
  - `git remote add upstream https://github.com/OHIF/Viewers.git`

@@ -44,7 +44,7 @@ choice for asserting an element's border color.

 Modern tooling gives us this "for free". It can catch invalid regular
 expressions, unused variables, and guarantee we're calling methods/functions
-with the expected paramater types.
+with the expected parameter types.

 Example Tooling:

@@ -56,7 +56,7 @@ export default {
   */
  id: 'example-extension',

-  // Lifecyle
+  // Lifecycle
  preRegistration() { /* */ },
  // Modules
  getCommandsModule() { /* */ },
@@ -65,7 +65,7 @@ myCommandName: {
 | Property        | Type               | Description                                                                                                                             |
 | --------------- | ------------------ | --------------------------------------------------------------------------------------------------------------------------------------- |
 | `commandFn`     | func               | The function to call when command is run. Receives `options` and `storeContexts`.                                                       |
-| `storeContexts` | string[]           | (optional) Expected state objects to be passed in as props. Located using `getAppState` fn defined at `CommandsManager`'s instatiation. |
+| `storeContexts` | string[]           | (optional) Expected state objects to be passed in as props. Located using `getAppState` fn defined at `CommandsManager`'s instantiation. |
 | `options`       | object             | (optional) Arguments to pass at the time of calling to the `commandFn`                                                                  |
 | `context`       | string[] or string | (optional) Overrides the `defaultContext`. Let's us know if command is currently "available" to be run.                                 |

@@ -150,7 +150,7 @@ It is up to the consuming application to define what contexts are possible, and
 which ones are currently active. As extensions depend heavily on these, we will
 likely publish guidance around creating contexts, and ways to override extension
 defined contexts in the near future. If you would like to discuss potential
-changes to how contexts work, please don't hesistate to createa new GitHub
+changes to how contexts work, please don't hesitate to create new GitHub
 issue.

 [Some additional information on Contexts can be found here.](./../index.md#contexts)
@@ -64,7 +64,7 @@ The simplest definition has the following properties:
 | `label`          | User/display friendly to show in UI                               | \*                                        |
 | `icon`           | A string name for an icon supported by the consuming application. | \*                                        |
 | `type`           | Used to determine the button's component and behavior             | `"setToolActive"`, `"command"`            |
-| `commandName`    | (optional) The command to run when the button is used.            | Any command registed by a `CommandModule` |
+| `commandName`    | (optional) The command to run when the button is used.            | Any command registered by a `CommandModule` |
 | `commandOptions` | (optional) Options to pass the target `commandName`               | \*                                        |
 | `context`        | (optional) Overrides module's `defaultContext`                    | Array of string context names             |

@@ -34,7 +34,7 @@ fixes, and target their minimum JS support whenever possible.
 An example of a polyfill is that you expect `Array.prototype.filter` to exist,
 but for some reason, the browser that's being used has not implemented that
 language feature yet. Our earlier transpilation will rectify _syntax_
-discrepencies, but unimplemented features require a "temporary" implementation.
+discrepancies, but unimplemented features require a "temporary" implementation.
 That's where polyfills step in.

 You can utilize a service like [polyfill.io](https://polyfill.io/v3/) to
@@ -4,7 +4,7 @@ sidebar_position: 2
 # Scope of Project

 The OHIF Viewer is a web based medical imaging viewer. This allows it to be used
-on almost any device, anywhere. The OHIF Viewer is what is commonly reffered to
+on almost any device, anywhere. The OHIF Viewer is what is commonly referred to
 as a ["Dumb Client"][simplicable]

 > A dumb client is software that fully depends on a connection to a server or
@@ -12,7 +12,7 @@ as a ["Dumb Client"][simplicable]
 > software offers nothing useful. - [simplicable.com][simplicable]

 While the Viewer persists some data, it's scope is limited to caching things
-like user preferences and previous query paramaters. Because of this, the Viewer
+like user preferences and previous query parameters. Because of this, the Viewer
 has been built to be highly configurable to work with almost any web accessible
 data source.

@@ -56,7 +56,7 @@ the OHIF Viewer as a desktop application.
 _Does the OHIF Viewer work with the local filesystem?_

 It is possible to accomplish this through extensions; however, for an user
-experience that accomodates a large number of studies, you would likely need to
+experience that accommodates a large number of studies, you would likely need to
 package the OHIF Viewer as an [Electron app][electron].

 <!--
@@ -19,7 +19,7 @@ Complex issues specific to your organization/situation are still okay to post,
 but they're less likely to receive a response. Unfortunately, we have limited
 resources and must be judicious with how we allocate them. If you find yourself
 in this situation and in need of assistance, it may be in your best interest to
-persue paid support.
+pursue paid support.

 ## Commercial Support

@@ -100,7 +100,7 @@ quality and test coverage must not changed by a significant margin. For some
 repositories, visual screenshot-based tests are also included, and video
 recordings of end-to-end tests are stored for later review.

-[You can read more about our continous integration efforts here](/development/continous-integration.md)
+[You can read more about our continuous integration efforts here](/development/continuous-integration.md)

 ## Releases

@@ -93,7 +93,7 @@ export default withTranslation('MyNameSpace')(MyComponent);

 > Important: if you are using React outside the OHIF Viewer, check the
 > [I18nextProvider](#using-outside-of-ohif-viewer) section, `withTranslation`
-> HOC doesnt works without a I18nextProvider
+> HOC doesn't works without a I18nextProvider

 #### Using Hooks

@@ -187,7 +187,7 @@ the following file tree:
            index.js
            | UK
               |-- Buttons.js
-               indes.js
+               index.js
            | US
               |-- Buttons.js
               index.js