fix various typos in docs

doc/manual/source/store/derivation/outputs/content-address.md

@@ -110,18 +110,18 @@ Because the derivation output is not fixed (just like with [input addressing]),
 >
 > Strictly speaking, the extent to which sandboxing and deprivilaging is possible varies with the environment Nix is running in.
 > Nix's configuration settings indicate what level of sandboxing is required or enabled.
-> Builds of derivations will fail if they request an absense of sandboxing which is not allowed.
-> Builds of derivations will also fail if the level of sandboxing specified in the configure exceeds what is possible in teh given environment.
+> Builds of derivations will fail if they request an absence of sandboxing which is not allowed.
+> Builds of derivations will also fail if the level of sandboxing specified in the configure exceeds what is possible in the given environment.
 >
-> (The "environment", in this case, consists of attributes such as the Operating System Nix runs atop, along with the operating-system-specific privilages that Nix has been granted.
-> Because of how conventional operating systems like macos, Linux, etc. work, granting builders *fewer* privilages may ironically require that Nix be run with *more* privilages.)
+> (The "environment", in this case, consists of attributes such as the Operating System Nix runs atop, along with the operating-system-specific privileges that Nix has been granted.
+> Because of how conventional operating systems like macos, Linux, etc. work, granting builders *fewer* privileges may ironically require that Nix be run with *more* privileges.)
 
 That said, derivations producing floating content-addressed outputs may declare their builders as impure (like the builders of derivations producing producing fixed outputs).
 This is provisionally supported as part of the [`impure-derivations`][xp-feature-impure-derivations] experimental feature.
 
 ### Compatibility negotiation
 
-Any derivation producing a floating content-addresssed output implicitly requires the `ca-derivations` [system feature](@docroot@/command-ref/conf-file.md#conf-system-features).
+Any derivation producing a floating content-addressed output implicitly requires the `ca-derivations` [system feature](@docroot@/command-ref/conf-file.md#conf-system-features).
 This prevents scheduling the building of the derivation on a machine without the experimental feature enabled.
 Even once the experimental feature is stabilized, this is still useful in order to be allow using remote builder running odler versions of Nix, or alternative implementations that do not support floating content addressing.
 
@@ -132,7 +132,7 @@ For store objects produced by manually inserting into the store to create a stor
 But for store objects produced by derivation, the "method is quite formal" --- the whole point of derivations is to be a formal notion of building, after all.
 In this case, we can elevate this informal property to a formal one.
 
-A *determinstic* content-addressing derivation should produce outputs with the same content addresses:
+A *deterministic* content-addressing derivation should produce outputs with the same content addresses:
 
 1. Every time the builder is run
 

doc/manual/source/store/derivation/outputs/index.md

@@ -2,7 +2,7 @@
 
 As stated on the [main pages on derivations](../index.md#store-derivation),
 a derivation produces [store objects](@docroot@/store/store-object.md), which are known as the *outputs* of the derivation.
-Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducably produce these derivations each time the derivation is run.
+Indeed, the entire point of derivations is to produce these outputs, and to reliably and reproducibly produce these derivations each time the derivation is run.
 
 One of the parts of a derivation is its *outputs specification*, which specifies certain information about the outputs the derivation produces when run.
 The outputs specification is a map, from names to specifications for individual outputs.

doc/manual/source/store/store-object.md

@@ -30,7 +30,7 @@ The *referrers* of a store object are the store objects that reference it.
 
 [transpose graph]: https://en.wikipedia.org/wiki/Transpose_graph
 
-One can also combine both concepts: taking the transitive closure of the tranposed references graph.
+One can also combine both concepts: taking the transitive closure of the transposed references graph.
 The *referrers closure* of a store object are the store objects that can reach the given store object via paths of references.
 
 > **Note**

doc/manual/source/store/store-object/content-address.md

@@ -45,7 +45,7 @@ Self-references however cannot be referred to by their path, because we are in t
 > As far as we know, this is equivalent to finding a hash collision.
 
 Instead we have a "has self-reference" boolean, which ends up affecting the digest:
-In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
+In all currently-supported store object content-addressing methods, when hashing the file system object data, any occurrence of store object's own store path in the digested data is replaced with a [sentinel value](https://en.wikipedia.org/wiki/Sentinel_value).
 The hashes of these modified input streams are used instead.
 
 When validating the content address of a store object after the fact, the above process works as written.