Merge pull request Sofie-Automation#1527 from rjmunro/rjmunro/fix-typos

Fix typos

Author: Julusian

_typos.toml

@@ -0,0 +1,20 @@
+[default]
+extend-ignore-identifiers-re = [
+	# Short Git hashes contained in square brackets
+    "[a-f0-9]{7}",
+]
+
+# [default.extend-identifiers]
+# # *sigh* this just isn't worth the cost of fixing
+# AttributeIDSupressMenu = "AttributeIDSupressMenu"
+
+[default.extend-words]
+ndi = "ndi"
+nd = "nd"
+anc = "anc"
+nexting = "nexting"
+loggin = "loggin"
+
+
+[files]
+extend-exclude = ["packages/documentation/versioned_docs", "packages/webui/public/locales", "*.po"]

meteor/CHANGELOG.md

@@ -20,7 +20,7 @@ Before any playout operation can proceed a studio and playlist lock must be crea
   - Check that no other rundown playlist in the studio is active
   - Reset the rundown if previously inactive
   - Set activationId and rehearsal mode on the playlist
-  - If there is no currenly active partInstance, set the first part as next
+  - If there is no currently active partInstance, set the first part as next
   - Update the timeline
   - Call the blueprints `onRundownActive` callback
 
@@ -147,7 +147,7 @@ _Prerequisites for activate: active playlist, current part, next part and hold s
 - Set the playlist hold state to PENDING
 - Update the timeline
 
-_Prerequisites for deactive: hold state is Pending_
+_Prerequisites for deactivate: hold state is Pending_
 
 - Set the playlist hold state to NONE
 - Update the timeline

meteor/CHANGELOG_0_x_x.md

@@ -242,7 +242,7 @@ All notable changes to this project will be documented in this file. See [standa
 ### Features
 
 - expose infinite ids of pieces to onTimelineGenerate ([401f30d](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/401f30d))
-- persistant state to onTimelineGenerate ([713c048](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/713c048))
+- persistent state to onTimelineGenerate ([713c048](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/713c048))
 
 ## [0.24.0](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/compare/0.23.0...0.24.0) (2019-06-18)
 
@@ -296,7 +296,7 @@ All notable changes to this project will be documented in this file. See [standa
 
 ### Features
 
-- Refacor sli and adlib types ([e6fc888](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/e6fc888))
+- Refactor sli and adlib types ([e6fc888](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/e6fc888))
 - Refactor typings for simpler ingest gateway interface ([5edd6e5](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/5edd6e5))
 - rename everything according to new naming schedule ([54268c5](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/54268c5))
 - split some types into simpler ones ([0a7fb06](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/0a7fb06))
@@ -539,7 +539,7 @@ All notable changes to this project will be documented in this file. See [standa
 
 ### Bug Fixes
 
-- **rundown:** Correct types of transisition duration properties on Part ([b0aec50](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/b0aec50))
+- **rundown:** Correct types of transition duration properties on Part ([b0aec50](https://github.com/nrkno/tv-automation-sofie-blueprints-integration/commit/b0aec50))
 
 <a name="0.4.0"></a>
 

meteor/server/api/playout/DOCS.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 solely 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:
@@ -81,7 +81,7 @@ Some of these collections are used by Package Manager to initiate work, while ot
 
 This category of collections is owned by the playout [worker threads](./worker-threads-and-locks.md), and is used to model the playout of a Rundown or set of Rundowns.
 
-During the final stage of an ingest operation, there is a period where the ingest worker aquires a `PlaylistLock`, so that it can ensure that the RundownPlaylist the Rundown is a part of is updated with any necessary changes following the ingest operation. During this lock, it will also attempt to [sync any ingest changes](./for-blueprint-developers/sync-ingest-changes) to the PartInstances and PieceInstances, if supported by the blueprints.
+During the final stage of an ingest operation, there is a period where the ingest worker acquires a `PlaylistLock`, so that it can ensure that the RundownPlaylist the Rundown is a part of is updated with any necessary changes following the ingest operation. During this lock, it will also attempt to [sync any ingest changes](./for-blueprint-developers/sync-ingest-changes) to the PartInstances and PieceInstances, if supported by the blueprints.
 
 As before, Meteor is allowed to write to these collections as part of migrations, and cleaning up old documents.
 
@@ -100,7 +100,7 @@ These collections are used in combination with many of the ingest collections, t
 RundownPlaylists are a Sofie invention designed to solve one problem; in some NRCS it is beneficial to build a show across multiple Rundowns, which should then be concatenated for playout.
 In particular, MOS has no concept of a Playlist, only Rundowns, and it was here where we need to be able to combine multiple Rundowns.
 
-This functionality can be used to either break down long shows into managable chunks, or to indicate a different type of show between the each portion.
+This functionality can be used to either break down long shows into manageable chunks, or to indicate a different type of show between the each portion.
 
 Because of this, RundownPlaylists are largely missing from the ingest side of Sofie. We do not expose them in the ingest APIs, or do anything with them throughout the majority of the blueprints generating a Rundown.
 Instead, we let the blueprints specify that a Rundown should be part of a RundownPlaylist by setting the `playlistExternalId` property, where multiple Rundowns in a Studio with the same id will be grouped into a RundownPlaylist.
@@ -126,6 +126,6 @@ Our solution to some of this early on was to not regenerate certain Parts when r
 
 At this point in time, Adlib Actions did not exist in Sofie. They are able to change almost every property of a Part of Piece that ingest is able to define, which makes the resetting process harder.
 
-PartInstances and PieceInstances were added as a way for us to make a copy of each Part and Piece, as it was selected for playout, so that we could allow ingest without risking affecting playout, and to simplify the cleanup performed. The PartInstances and PieceInstances are our record of how the Rundown was played, which we can utilise to output metadata such as for chapter markers on a web player. In earlier versions of Sofie this was tracked independently with an `AsRunLog`, which resulted in odd issues such as having `AsRunLog` entries which refered to a Part which no longer existed, or whose content was very different to how it was played.
+PartInstances and PieceInstances were added as a way for us to make a copy of each Part and Piece, as it was selected for playout, so that we could allow ingest without risking affecting playout, and to simplify the cleanup performed. The PartInstances and PieceInstances are our record of how the Rundown was played, which we can utilise to output metadata such as for chapter markers on a web player. In earlier versions of Sofie this was tracked independently with an `AsRunLog`, which resulted in odd issues such as having `AsRunLog` entries which referred to a Part which no longer existed, or whose content was very different to how it was played.
 
 Later on, this separation has allowed us to more cleanly define operations as ingest or playout, and allows us to run them in parallel with more confidence that they won't accidentally wipe out each others changes. Previously, both ingest and playout operations would be modifying documents in the Piece and Part collections, making concurrent operations unsafe as they could be modifying the same Part or Piece.

packages/blueprints-integration/CHANGELOG-legacy.md

@@ -1,6 +1,6 @@
 # Introduction
 
-Device integrations in Sofie are part of the Timeline State Resolver (TSR) library. A device integration has a couple of responsibilites in the Sofie eco system. First and foremost it should establish a connection with a foreign device. It should also be able to convert Sofie's idea of what the device should be doing into commands to control the device. And lastly it should export interfaces to be used by the blueprints developer.
+Device integrations in Sofie are part of the Timeline State Resolver (TSR) library. A device integration has a couple of responsibilities in the Sofie eco system. First and foremost it should establish a connection with a foreign device. It should also be able to convert Sofie's idea of what the device should be doing into commands to control the device. And lastly it should export interfaces to be used by the blueprints developer.
 
 In order to understand all about writing TSR integrations there are some concepts to familiarise yourself with, in this documentation we will attempt to explain these.
 
@@ -9,9 +9,9 @@ In order to understand all about writing TSR integrations there are some concept
 - [TSR Types package](./tsr-types.html)
 - [TSR Actions](./tsr-actions.html)
 
-But to start of we will explain the general structure of the TSR. Any user of the TSR will interface primarily with the Conductor class. Primarily the user will input device configurations, mappings and timelines into the TSR. The timeline describes the entire state of all of the devices over time. It does this by putting objects on timeline layers. Every timeline layer maps to a specific part of the device, this is configured throught the mappings.
+But to start off we will explain the general structure of the TSR. Any user of the TSR will interface primarily with the Conductor class. Primarily the user will input device configurations, mappings and timelines into the TSR. The timeline describes the entire state of all of the devices over time. It does this by putting objects on timeline layers. Every timeline layer maps to a specific part of the device, this is configured through the mappings.
 
-The timeline is converted into disctinct states at different points in time, and these states are fed to the individual integrations. As an integration developer you shouldn't have to worry about keeping track of this. It is most important that you expose \(a\) a method to convert from a Timeline State to a Device State, \(b\) a method for diffing 2 device states and (c) a way to send commands to the device. We'll dive deeper into this in [TSR Integration API](./tsr-api.html).
+The timeline is converted into disctinct states at different points in time, and these states are fed to the individual integrations. As an integration developer you shouldn't have to worry about keeping track of this. It is most important that you expose \(a\) a method to convert from a Timeline State to a Device State, \(b\) a method for diffing 2 device states and \(c\) a way to send commands to the device. We'll dive deeper into this in [TSR Integration API](./tsr-api.html).
 
 :::info
 The information in this section is not a conclusive guide on writing an integration, it should be use more as a guide to use while looking at a TSR integration such as the [OSC integration](https://github.com/Sofie-Automation/sofie-timeline-state-resolver/tree/master/packages/timeline-state-resolver/src/integrations/osc).

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

@@ -38,7 +38,7 @@ export enum LookaheadMode {
 }
 ```
 
-If undefined, `lookaheadMaxSearchDistance` currently has a default distance of 10 parts. This number was chosen arbitrarily, and could change in the future. Be careful when choosing a distance to not set it too high. All the Pieces from the parts being searched have to be loaded from the database, which can come at a noticable cost.
+If undefined, `lookaheadMaxSearchDistance` currently has a default distance of 10 parts. This number was chosen arbitrarily, and could change in the future. Be careful when choosing a distance to not set it too high. All the Pieces from the parts being searched have to be loaded from the database, which can come at a noticeable cost.
 
 If you are doing [AB Playback](./ab-playback.md), or performing some other processing of the timeline in `onTimelineGenerate`, you may benefit from increasing the value of `lookaheadDepth`. In the case of AB Playback, you will likely want to set it to the number of players available in your pool.
 

packages/documentation/docs/for-developers/device-integrations/intro.md

@@ -7,7 +7,7 @@ At times it can be useful to manipulate this data before it gets passed into the
 
 A new method `processIngestData` was added to transform the `NRCSIngestRundown` into a `SofieIngestRundown`. The types of the two are the same, so implementing the `processIngestData` method is optional, with the default being to pass through the NRCS rundown unchanged. (There is an exception here for MOS, which is explained below).
 
-The basic implementation of this method which simply propogates nrcs changes is:
+The basic implementation of this method which simply propagates nrcs changes is:
 
 ```ts
 function processIngestData(

packages/documentation/docs/for-developers/for-blueprint-developers/lookahead.md

@@ -131,7 +131,7 @@ const inTransition = {
 
 Pieces with an infinite lifespan (ie, not `lifespan: PieceLifespan.WithinPart`) get handled differently to other pieces.
 
-Only one pieceGoup is created for an infinite Piece which is present in multiple of the current, next and previous Parts.  
+Only one pieceGroup is created for an infinite Piece which is present in multiple of the current, next and previous Parts.  
 The Piece calculates and tracks its own started playback times, which is preserved and reused in future takes. On the timeline it lives outside of the partGroups, but still gets the same caps applied when appropriate.
 
 ### Interactive timings demo