chore(docs): word capitalization

Author: jstarpl

packages/documentation/docs/for-developers/data-model.md

@@ -18,7 +18,7 @@ In every case, any layout changes and any scheduled cleanup are performed by the
 
 This category of collections is rather loosely defined, as it ends up being everything that doesn't belong somewhere else
 
-This consists of anything that is configurable from the Sofie UI, anything needed soley for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by package manager, through an API over DDP.  
+This consists of anything that is configurable from the Sofie UI, anything needed soley for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by Package Manager, through an API over DDP.  
 Currently, there is not a very clearly defined flow for modifying these documents, with the UI often making changes directly with minimal or no validation.
 
 This includes:
@@ -76,7 +76,7 @@ The collections which are owned by the ingest workers are:
 - [Segments](https://github.com/nrkno/sofie-core/blob/master/packages/corelib/src/dataModel/Segments.ts)
 
 These collections model a Rundown from the NRCS in a Sofie form. Almost all of these contain documents which are largely generated by blueprints.  
-Some of these collections are used by package manager to initiate work, while others form a view of the Rundown for the users, and are used as part of the model for playout.
+Some of these collections are used by Package Manager to initiate work, while others form a view of the Rundown for the users, and are used as part of the model for playout.
 
 ### Playout
 

packages/documentation/docs/for-developers/json-config-schema.md

@@ -55,7 +55,7 @@ Names of the enum values as generated for the typescript enum, which we display
 
 Note: Only valid for blueprint configuration.
 
-Sometimes it can be useful to reference other values. This property can be used on string fields, to let sofie generate a dropdown populated with values valid in the current context.
+Sometimes it can be useful to reference other values. This property can be used on string fields, to let Sofie generate a dropdown populated with values valid in the current context.
 
 #### `mappings`
 

packages/documentation/docs/for-developers/publications.md

@@ -32,7 +32,7 @@ There has been a recent push towards using more 'custom' publications for stream
 To achieve this, we have an `optimisedObserver` flow which is designed to help maange to a custom publication, with a few methods to fill in to setup the reactivity and the data transformation.
 
 One such publication is the `PieceContentStatus`, prior to version 1.50, this was computed inside the UI.  
-A brief overview of this publication, is that it looks at each Piece in a Rundown, and reports whether the Piece is 'OK'. This check is primarily focussed on Pieces containing clips, where it will check the metadata generated by either package manager or media manager to ensure that the clip is marked as being ready for playout, and that it has the correct format and some other quality checks.
+A brief overview of this publication, is that it looks at each Piece in a Rundown, and reports whether the Piece is 'OK'. This check is primarily focussed on Pieces containing clips, where it will check the metadata generated by Package Manager to ensure that the clip is marked as being ready for playout, and that it has the correct format and some other quality checks.
 
 To do this on the client meant needing to subscribe to the whole contents of a couple of MongoDB collections, as it is not easy to determine which documents will be needed until the check is being run. This caused some issues as these collections could get rather large. We also did not always have every Piece loaded in the UI, so had to defer some of the computation to the backend via polling.
 

packages/documentation/docs/user-guide/features/access-levels.md

@@ -7,7 +7,7 @@ sidebar_position: 3
 ## Permissions
 
 There are a few different access levels that users can be assigned. They are not heirarchical, you will often need to enable multiple for each user.
-Any client that can access sofie always has at least view-only access to the rundowns, and system status pages.
+Any client that can access Sofie always has at least view-only access to the rundowns, and system status pages.
 
 | Level         | Summary                                                                                                                                          |
 | :------------ | :----------------------------------------------------------------------------------------------------------------------------------------------- |

packages/documentation/docs/user-guide/installation/installing-package-manager.md

@@ -18,14 +18,14 @@ Although Package Manager can be used to copy any kind of file to/from a wide arr
 
 :::caution
 
-Sofie supports only one package manager running for a Studio. Attaching more at a time will result in weird behaviour due to them fighting over reporting the statuses of packages.  
-If you feel like you need multiple, then you likely want to run package manager in the distributed setup instead.
+Sofie supports only one Package Manager running for a Studio. Attaching more at a time will result in weird behaviour due to them fighting over reporting the statuses of packages.  
+If you feel like you need multiple, then you likely want to run Package Manager in the distributed setup instead.
 
 :::
 
 :::caution
 
-The package manager worker process is primarily tested on Windows only. It does run on Linux (without support for network shares), but has not been extensively tested.
+The Package Manager worker process is primarily tested on Windows only. It does run on Linux (without support for network shares), but has not been extensively tested.
 
 :::
 
@@ -58,7 +58,7 @@ This first run is necessary to get the Package Manager device registered with _S
 
 ## Installation In Production
 
-Only one package manager can be running for a Sofie Studio. If you reached this point thinking of deploying multiple, you will want to follow the distributed setup.
+Only one Package Manager can be running for a Sofie Studio. If you reached this point thinking of deploying multiple, you will want to follow the distributed setup.
 
 ### Simple Setup
 
@@ -78,7 +78,7 @@ When configuring the http proxy server in Sofie, you may need to follow extra co
 
 ### Distributed Setup
 
-For setups where you need to interact with multiple CasparCG machines, or want a more resilient/scalable setup, package manager can be partially deployed in Docker, with just the workers running on each CasparCG machine.
+For setups where you need to interact with multiple CasparCG machines, or want a more resilient/scalable setup, Package Manager can be partially deployed in Docker, with just the workers running on each CasparCG machine.
 
 An example `docker-compose` of the setup is as follows:
 
@@ -110,7 +110,7 @@ services:
       context: .
       dockerfile: sofietv/package-manager-package-manager
     environment:
-      CORE_HOST: '172.18.0.1' # the address for connecting back to sofie core from this image
+      CORE_HOST: '172.18.0.1' # the address for connecting back to Sofie core from this image
       CORE_PORT: '3000'
       DEVICE_ID: 'my-package-manager-id'
       DEVICE_TOKEN: 'some-secret'
@@ -133,7 +133,7 @@ In addition to this, you will need to run the appContainer and workers on each w
 ./appContainer-node.exe
   --appContainerId=caspar01 // This is a unique id for this instance of the appContainer
   --workforceURL=ws://workforce-service-ip:8070
-  --resourceId=caspar01 // This should also be set in the 'resource id' field of the `casparcgLocalFolder1` accessor. This is how package manager can identify which machine is which.
+  --resourceId=caspar01 // This should also be set in the 'resource id' field of the `casparcgLocalFolder1` accessor. This is how Package Manager can identify which machine is which.
   --networkIds=pm-net // This is not necessary, but can be useful for more complex setups
 ```
 
@@ -144,7 +144,7 @@ Note that each appContainer needs to use a different resourceId and will need it
 ## Configuration
 
 1. Open the _Sofie Core_ Settings page ([http://localhost:3000/settings?admin=1](http://localhost:3000/settings?admin=1)), click on your Studio, and then Peripheral Devices.
-1. Click the plus button (`+`) in the Parent Devices section and configure the created device to be for your Package manager.
+1. Click the plus button (`+`) in the Parent Devices section and configure the created device to be for your Package Manager.
 1. On the sidebar under the current Studio, select to the Package Manager section.
 1. Click the plus button under the Package Containers heading, then click the edit icon (pencil) to the right of the newly-created package container.
 1. Give this package container an ID of `casparcgContainer0` and a label of `CasparCG Package Container`.
@@ -167,7 +167,7 @@ By adding `--networkIds=pm-net` (a semi colon separated list) when launching the
 
 Then in the Sofie UI:
 
-1. Return to the Package manager settings under the studio
+1. Return to the Package Manager settings under the studio
 1. Expand the `casparcgContainer` container.
 1. Edit the `casparcgHttpProxy` accessor to have a `Base URL` that is accessible from the casparcg machines.
 1. Set the `Network ID` to `pm-net` (matching what was passed in the command line)

packages/documentation/versioned_docs/version-1.50.0/for-developers/data-model.md

@@ -18,7 +18,7 @@ In every case, any layout changes and any scheduled cleanup are performed by the
 
 This category of collections is rather loosely defined, as it ends up being everything that doesn't belong somewhere else
 
-This consists of anything that is configurable from the Sofie UI, anything needed soley for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by package manager, through an API over DDP.  
+This consists of anything that is configurable from the Sofie UI, anything needed soley for the UI and some other bits. Additionally, there are some collections which are populated by other portions of a Sofie system, such as by Package Manager, through an API over DDP.  
 Currently, there is not a very clearly defined flow for modifying these documents, with the UI often making changes directly with minimal or no validation.
 
 This includes:
@@ -76,7 +76,7 @@ The collections which are owned by the ingest workers are:
 - [Segments](https://github.com/nrkno/sofie-core/blob/master/packages/corelib/src/dataModel/Segments.ts)
 
 These collections model a Rundown from the NRCS in a Sofie form. Almost all of these contain documents which are largely generated by blueprints.  
-Some of these collections are used by package manager to initiate work, while others form a view of the Rundown for the users, and are used as part of the model for playout.
+Some of these collections are used by Package Manager to initiate work, while others form a view of the Rundown for the users, and are used as part of the model for playout.
 
 ### Playout
 

packages/documentation/versioned_docs/version-1.50.0/for-developers/json-config-schema.md

@@ -55,7 +55,7 @@ Names of the enum values as generated for the typescript enum, which we display
 
 Note: Only valid for blueprint configuration.
 
-Sometimes it can be useful to reference other values. This property can be used on string fields, to let sofie generate a dropdown populated with values valid in the current context.
+Sometimes it can be useful to reference other values. This property can be used on string fields, to let Sofie generate a dropdown populated with values valid in the current context.
 
 #### `mappings`
 

packages/documentation/versioned_docs/version-1.50.0/for-developers/publications.md

@@ -32,7 +32,7 @@ There has been a recent push towards using more 'custom' publications for stream
 To achieve this, we have an `optimisedObserver` flow which is designed to help maange to a custom publication, with a few methods to fill in to setup the reactivity and the data transformation.
 
 One such publication is the `PieceContentStatus`, prior to version 1.50, this was computed inside the UI.  
-A brief overview of this publication, is that it looks at each Piece in a Rundown, and reports whether the Piece is 'OK'. This check is primarily focussed on Pieces containing clips, where it will check the metadata generated by either package manager or media manager to ensure that the clip is marked as being ready for playout, and that it has the correct format and some other quality checks.
+A brief overview of this publication, is that it looks at each Piece in a Rundown, and reports whether the Piece is 'OK'. This check is primarily focussed on Pieces containing clips, where it will check the metadata generated by either Package Manager or media manager to ensure that the clip is marked as being ready for playout, and that it has the correct format and some other quality checks.
 
 To do this on the client meant needing to subscribe to the whole contents of a couple of MongoDB collections, as it is not easy to determine which documents will be needed until the check is being run. This caused some issues as these collections could get rather large. We also did not always have every Piece loaded in the UI, so had to defer some of the computation to the backend via polling.