’ -> ' (#1649)

src/appendices/coordinate-systems.md

@@ -221,7 +221,7 @@ However, their use is [DEPRECATED][deprecated].
 
 | **Coordinate System**               | **Description**                                                                                                                                          | **RECOMMENDED alternative identifier** |
 | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------- |
-| fsaverage\[3\|4\|5\|6\|sym\]        | Images were sampled to the FreeSurfer surface reconstructed from the subject’s T1w image, and registered to an fsaverage template                        | fsaverage\[Sym\]                       |
+| fsaverage\[3\|4\|5\|6\|sym\]        | Images were sampled to the FreeSurfer surface reconstructed from the subject's T1w image, and registered to an fsaverage template                        | fsaverage\[Sym\]                       |
 | UNCInfant\[0\|1\|2\]V\[21\|22\|23\] | Infant Brain Atlases from Neonates to 1- and 2-year-olds. [https://www.nitrc.org/projects/pediatricatlas](https://www.nitrc.org/projects/pediatricatlas) | UNCInfant                              |
 
 ### Nonstandard coordinate system identifiers

src/appendices/meg-file-formats.md

@@ -57,7 +57,7 @@ A guide for using macros can be found at
    }
 ) }}
 
-To learn more about CTF’s data organization
+To learn more about CTF's data organization
 on the relevant [FieldTrip webpage](https://www.fieldtriptoolbox.org/getting_started/ctf/)
 
 ## Neuromag/Elekta/MEGIN
@@ -408,7 +408,7 @@ header that contains detailed information about the data acquisition system,
 followed by binary data. The associated binary header file contains part of the
 information from the ASCII header, specifically the one needed to process data,
 plus other information on offline preprocessing performed after data acquisition
-(for example, sensor position relative to subject’s head, head markers, stimulus
+(for example, sensor position relative to subject's head, head markers, stimulus
 information).
 
 Example:

src/common-principles.md

@@ -393,7 +393,7 @@ include a `dataset_description.json` file at the root level (see
 [Dataset description][dataset-description]).
 Consequently, files should be organized to comply with BIDS to the full extent
 possible (that is, unless explicitly contradicted for derivatives).
-Any subject-specific derivatives should be housed within each subject’s directory;
+Any subject-specific derivatives should be housed within each subject's directory;
 if session-specific derivatives are generated, they should be deposited under a
 session subdirectory within the corresponding subject directory; and so on.
 

src/derivatives/common-data-types.md

@@ -249,7 +249,7 @@ A guide for using macros can be found at
    }
 ) }}
 
-All REQUIRED metadata fields coming from a derivative file’s source file(s) MUST
+All REQUIRED metadata fields coming from a derivative file's source file(s) MUST
 be propagated to the JSON description of the derivative unless the processing
 makes them invalid (for example, if a source 4D image is averaged to create a single
 static volume, a `RepetitionTime` property would no longer be relevant).

src/derivatives/introduction.md

@@ -39,13 +39,13 @@ in [Derived dataset and pipeline description][derived-dataset-description].
     pertinent fields is very valuable and thus encouraged. Moreover, for some
     types of files, there may be one or more required metadata fields, in which
     case at least one metadata file containing that field must be located
-    somewhere within the file’s hierarchy (per the
+    somewhere within the file's hierarchy (per the
     [Inheritance Principle](../common-principles.md#the-inheritance-principle)).
 
 -   When chaining derivative pipelines, any JSON fields that were specified as
     mandatory in the input files SHOULD be propagated forward in the output
-    file’s JSON provided they remain valid. Non-required JSON fields MAY be
-    propagated, and are highly useful, but it is the pipeline’s responsibility
+    file's JSON provided they remain valid. Non-required JSON fields MAY be
+    propagated, and are highly useful, but it is the pipeline's responsibility
     to ensure that the values are still relevant and appropriate to the type of
     output data.
 

src/modality-specific-files/magnetoencephalography.md

@@ -442,7 +442,7 @@ and a guide for using macros can be found at
 {{ MACROS___make_filename_template("raw", datatypes=["meg"], suffixes=["photo"]) }}
 
 Photos of the anatomical landmarks and/or head localization coils on the
-subject’s head are RECOMMENDED. If the coils are not placed at the location of
+subject's head are RECOMMENDED. If the coils are not placed at the location of
 actual anatomical landmarks, these latter may be marked with a piece of felt-tip
 taped to the skin. Please note that the photos may need to be cropped or blurred
 to conceal identifying features prior to sharing, depending on the terms of the
@@ -476,7 +476,7 @@ The 3-D locations of points that describe the head shape and/or EEG
 electrode locations can be digitized and stored in separate files. The
 [`acq-<label>`](../appendices/entities.md#acq) entity can be used when more than one type of digitization in done for
 a session, for example when the head points are in a separate file from the EEG
-locations. These files are stored in the specific format of the 3-D digitizer’s
+locations. These files are stored in the specific format of the 3-D digitizer's
 manufacturer (see the [MEG File Formats Appendix](../appendices/meg-file-formats.md)).
 
 For example:

src/modality-specific-files/microscopy.md

@@ -37,7 +37,7 @@ by the [Open Microscopy Environment](https://www.openmicroscopy.org/) for whole-
 the [OME-TIFF file specifications](https://docs.openmicroscopy.org/ome-model/6.1.2/ome-tiff/file-structure.html).
 The OME-TIFF file allows for multi-page TIFF files to store multiple image planes and supports
 multi-resolution pyramidal tiled images. An OME-XML data block is also embedded inside the
-file’s header. Further, OME-ZARR (sometimes referred to as OME-NGFF or NGFF) has been developed to provide improved
+file's header. Further, OME-ZARR (sometimes referred to as OME-NGFF or NGFF) has been developed to provide improved
 access and storage for large data via chunked and compressed N-dimensional arrays.
 
 The BIDS standard accepts microscopy data in a number of file formats to accommodate datasets