Fix a few minor documentation typos

docs/concatenation.rst

@@ -69,7 +69,7 @@ For example, given two anndata objects with differing variables:
            [0., 1., 0.],
            [1., 0., 0.]])
 
-The join argument is used for any element which has both (1) an axis being concatenated and (2) has an axis not being concatenated.
+The join argument is used for any element which has both (1) an axis being concatenated and (2) an axis not being concatenated.
 When concatenating along the `obs` dimension, this means elements of `.X`, `obs`, `.layers`, and `.obsm` will be affected by the choice of `join`.
 
 To demonstrate this, let's say we're trying to combine a droplet based experiment with a spatial one.
@@ -153,7 +153,7 @@ We provide a few strategies for merging elements aligned to the alternative axes
 * `None`: No elements aligned to alternative axes are present in the result object.
 * `"same"`: Elements that are the same in each of the objects.
 * `"unique"`: Elements for which there is only one possible value.
-* `"first"`: The first element seen at each from each position.
+* `"first"`: The first element seen in each from each position.
 * `"only"`: Elements that show up in only one of the objects.
 
 We'll show how this works with elements aligned to the alternative axis, and then how merging works with `.uns`.
@@ -187,7 +187,7 @@ Now we will split this object by the categorical `"blobs"` and recombine it to i
 
 `adatas` is now a list of datasets with disjoint sets of observations and a common set of variables.
 Each object has had QC metrics computed, with observation-wise metrics stored under `"qc"` in `.obsm`, and variable-wise metrics stored with a unique key for each subset.
-Taking a look at how this effects concatenation:
+Taking a look at how this affects concatenation:
 
     >>> ad.concat(adatas)
     AnnData object with n_obs × n_vars = 640 × 30

docs/fileformat-prose.md

@@ -57,10 +57,10 @@ var                      Group
 varm                     Group
 ``` -->
 
-In general, `AnnData` objects are comprised of a various types of elements.
+In general, `AnnData` objects are comprised of various types of elements.
 Each element is encoded as either an Array (or Dataset in hdf5 terminology) or a collection of elements (e.g. Group) in the store.
-We record the type of an element using the `encoding-type` and `encoding-version` keys in it's attributes.
-For example, we can this file represents an `AnnData` object from this metadata:
+We record the type of an element using the `encoding-type` and `encoding-version` keys in its attributes.
+For example, we can see that this file represents an `AnnData` object from its metadata:
 
 ```python
 >>> dict(store.attrs)
@@ -319,7 +319,7 @@ pca/variance_ratio <zarr.core.Array '/uns/pca/variance_ratio' (50,) float64 read
 ### Mapping specifications (v0.1.0)
 
 * Each mapping MUST be its own group
-* The groups metadata MUST contain the encoding metadata `"encoding-type": "dict"`, `"encoding-version": "0.1.0"`
+* The group's metadata MUST contain the encoding metadata `"encoding-type": "dict"`, `"encoding-version": "0.1.0"`
 
 ## Scalars
 
@@ -426,7 +426,7 @@ codes <zarr.core.Array '/obs/development_stage/codes' (164114,) int8 read-only>
 ## String arrays
 
 Arrays of strings are handled differently than numeric arrays since numpy doesn't really have a good way of representing arrays of unicode strings.
-`anndata` assumes strings are text-like data, so uses a variable length encoding.
+`anndata` assumes strings are text-like data, so it uses a variable length encoding.
 
 `````{tab-set}