Fix broken links in v1.52.0 docs

Author: rjmunro

packages/documentation/versioned_docs/version-1.52.0/for-developers/device-integrations/intro.md

@@ -4,14 +4,14 @@ Device integrations in Sofie are part of the Timeline State Resolver (TSR) libra
 
 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.
 
-- [Options and mappings](./options-and-mappings.html)
-- [TSR Integration API](./tsr-api.html)
-- [TSR Types package](./tsr-types.html)
-- [TSR Actions](./tsr-actions.html)
+- [Options and mappings](./options-and-mappings)
+- [TSR Integration API](./tsr-api)
+- [TSR Types package](./tsr-types)
+- [TSR Actions](./tsr-actions)
 
 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.
 
-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).
 
 :::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/main/packages/timeline-state-resolver/src/integrations/osc).

packages/documentation/versioned_docs/version-1.52.0/for-developers/device-integrations/options-and-mappings.md

@@ -1,6 +1,6 @@
 # Options and mappings
 
-For an end user to configure the system from the Sofie UI we have to expose options and mappings from the TSR. This is done through [JSON config schemas](../json-config-schema.html) in the `$schemas` folder of your integration.
+For an end user to configure the system from the Sofie UI we have to expose options and mappings from the TSR. This is done through [JSON config schemas](../json-config-schema) in the `$schemas` folder of your integration.
 
 ## Options
 

packages/documentation/versioned_docs/version-1.52.0/user-guide/concepts-and-architecture.md

@@ -27,7 +27,7 @@ To be able to facilitate various workflows and to Here's a short explanation abo
 - The **System** defines the whole of the Sofie Core
 - The **Organization** \(only available if user accounts are enabled\) defines things that are common for an organization. An organization consists of: **Users, Studios** and **ShowStyles**.
 - The **Studio** contains things that are related to the "hardware" or "rig". Technically, a Studio is defined as an entity that can have one \(or none\) rundown active at any given time. In most cases, this will be a representation of your gallery, with cameras, video playback and graphics systems, external inputs, sound mixers, lighting controls and so on. A single System can easily control multiple Studios.
-- The **Show Style** contains settings for the "show", for example if there's a "Morning Show" and an "Afternoon Show" - produced in the same gallery - they might be two different Show Styles \(played in the same Studio\). Most importantly, the Show Style decides the "look and feel" of the Show towards the producer/director, dictating how data ingested from the NRCS will be interpreted and how the user will interact with the system during playback (see: [Show Style](../configuration/settings-view#show-style) in Settings).
+- The **Show Style** contains settings for the "show", for example if there's a "Morning Show" and an "Afternoon Show" - produced in the same gallery - they might be two different Show Styles \(played in the same Studio\). Most importantly, the Show Style decides the "look and feel" of the Show towards the producer/director, dictating how data ingested from the NRCS will be interpreted and how the user will interact with the system during playback (see: [Show Style](./configuration/settings-view#show-style) in Settings).
   - A **Show Style Variant** is a set of Show Style _Blueprint_ configuration values, that allows to use the same interaction model across multiple Shows with potentially different assets, changing the outward look of the Show: for example news programs with different hosts produced from the same Studio, but with different light setups, backscreen and overlay graphics.
 
 ![Sofie Architecture Venn Diagram](/img/docs/main/features/sofie-venn-diagram.png)