sphinx: replace special quotes with single and double quotes

(From yocto-docs rev: 0aeb7a94abcef3cb3850c753dd0a243f381e6675)

Signed-off-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

4 files changed, 24 insertions, 24 deletions

diff --git a/documentation/test-manual/test-manual-intro.rst b/documentation/test-manual/test-manual-intro.rst
index b0bc24c9b0..53ad650b35 100644
--- a/documentation/test-manual/test-manual-intro.rst
+++ b/documentation/test-manual/test-manual-intro.rst
@@ -12,9 +12,9 @@ Welcome
 Welcome to the Yocto Project Test Environment Manual! This manual is a
 work in progress. The manual contains information about the testing
 environment used by the Yocto Project to make sure each major and minor
-release works as intended. All the project’s testing infrastructure and
+release works as intended. All the project's testing infrastructure and
 processes are publicly visible and available so that the community can
-see what testing is being performed, how it’s being done and the current
+see what testing is being performed, how it's being done and the current
 status of the tests and the project at any given time. It is intended
 that Other organizations can leverage off the process and testing
 environment used by the Yocto Project to create their own automated,
@@ -514,7 +514,7 @@ resource utilisation as that happens. An example from
                      'bitbake -p (cached)')
 
 This example shows how three specific parsing timings are
-measured, with and without various caches, to show how BitBake’s parsing
+measured, with and without various caches, to show how BitBake's parsing
 performance trends over time.
 
 .. _test-writing-considerations:
diff --git a/documentation/test-manual/test-manual-intro.xml b/documentation/test-manual/test-manual-intro.xml
index 8e2c7cd874..0cdbee4d8e 100644
--- a/documentation/test-manual/test-manual-intro.xml
+++ b/documentation/test-manual/test-manual-intro.xml
@@ -12,8 +12,8 @@
         <para> Welcome to the Yocto Project Test Environment Manual! This manual is a work in
             progress. The manual contains information about the testing environment used by the
             Yocto Project to make sure each major and minor release works as intended. All the
-            project’s testing infrastructure and processes are publicly visible and available so
-            that the community can see what testing is being performed, how it’s being done and the
+            project's testing infrastructure and processes are publicly visible and available so
+            that the community can see what testing is being performed, how it's being done and the
             current status of the tests and the project at any given time. It is intended that Other
             organizations can leverage off the process and testing environment used by the Yocto
             Project to create their own automated, production test environment, building upon the
@@ -579,7 +579,7 @@
                                       'bitbake -p (cached)')
                     </literallayout>This
                 example shows how three specific parsing timings are measured, with and without
-                various caches, to show how BitBake’s parsing performance trends over time.</para>
+                various caches, to show how BitBake's parsing performance trends over time.</para>
         </section>
     </section>
     <section id='test-writing-considerations'>
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.rst b/documentation/test-manual/test-manual-understand-autobuilder.rst
index 0809190b5b..2fcae5000e 100644
--- a/documentation/test-manual/test-manual-understand-autobuilder.rst
+++ b/documentation/test-manual/test-manual-understand-autobuilder.rst
@@ -7,19 +7,19 @@ Understanding the Yocto Project Autobuilder
 Execution Flow within the Autobuilder
 =====================================
 
-The “a-full” and “a-quick” targets are the usual entry points into the
+The "a-full" and "a-quick" targets are the usual entry points into the
 Autobuilder and it makes sense to follow the process through the system
 starting there. This is best visualised from the Autobuilder Console
 view (:yocto_ab:`/typhoon/#/console`).
 
-Each item along the top of that view represents some “target build” and
-these targets are all run in parallel. The ‘full’ build will trigger the
-majority of them, the “quick” build will trigger some subset of them.
+Each item along the top of that view represents some "target build" and
+these targets are all run in parallel. The 'full' build will trigger the
+majority of them, the "quick" build will trigger some subset of them.
 The Autobuilder effectively runs whichever configuration is defined for
 each of those targets on a seperate buildbot worker. To understand the
 configuration, you need to look at the entry on ``config.json`` file
 within the ``yocto-autobuilder-helper`` repository. The targets are
-defined in the ‘overrides’ section, a quick example could be qemux86-64
+defined in the ‘overrides' section, a quick example could be qemux86-64
 which looks like::
 
    "qemux86-64" : {
@@ -32,8 +32,8 @@ which looks like::
         }
    },
 
-And to expand that, you need the “arch-qemu” entry from
-the “templates” section, which looks like::
+And to expand that, you need the "arch-qemu" entry from
+the "templates" section, which looks like::
 
    "arch-qemu" : {
          "BUILDINFO" : true,
@@ -54,9 +54,9 @@ the “templates” section, which looks like::
          }
    },
 
-Combining these two entries you can see that “qemux86-64” is a three step build where the
+Combining these two entries you can see that "qemux86-64" is a three step build where the
 ``bitbake BBTARGETS`` would be run, then ``bitbake SANITYTARGETS`` for each step; all for
-``MACHINE=”qemx86-64”`` but with differing SDKMACHINE settings. In step
+``MACHINE="qemx86-64"`` but with differing SDKMACHINE settings. In step
 1 an extra variable is added to the ``auto.conf`` file to enable wic
 image generation.
 
@@ -262,7 +262,7 @@ of post-build steps, including:
 
 #. Cleanup the build directory using
    :ref:`test-manual/test-manual-understand-autobuilder:clobberdir` if the build was successful,
-   else rename it to “build-renamed” for potential future debugging.
+   else rename it to "build-renamed" for potential future debugging.
 
 .. _test-deploying-yp-autobuilder:
 
diff --git a/documentation/test-manual/test-manual-understand-autobuilder.xml b/documentation/test-manual/test-manual-understand-autobuilder.xml
index a04006605f..8600367be7 100644
--- a/documentation/test-manual/test-manual-understand-autobuilder.xml
+++ b/documentation/test-manual/test-manual-understand-autobuilder.xml
@@ -8,18 +8,18 @@
 <title>Understanding the Yocto Project Autobuilder</title>
     <section>
         <title>Execution Flow within the Autobuilder</title>
-        <para>The “a-full” and “a-quick” targets are the usual entry points into the Autobuilder and
+        <para>The "a-full" and "a-quick" targets are the usual entry points into the Autobuilder and
             it makes sense to follow the process through the system starting there. This is best
             visualised from the Autobuilder Console view (<link linkend=""
                 >https://autobuilder.yoctoproject.org/typhoon/#/console</link>). </para>
-        <para>Each item along the top of that view represents some “target build” and these targets
-            are all run in parallel. The ‘full’ build will trigger the majority of them, the “quick”
+        <para>Each item along the top of that view represents some "target build" and these targets
+            are all run in parallel. The 'full' build will trigger the majority of them, the "quick"
             build will trigger some subset of them. The Autobuilder effectively runs whichever
             configuration is defined for each of those targets on a seperate buildbot worker. To
             understand the configuration, you need to look at the entry on
                 <filename>config.json</filename> file within the
                 <filename>yocto-autobuilder-helper</filename> repository. The targets are defined in
-            the ‘overrides’ section, a quick example could be qemux86-64 which looks
+            the ‘overrides' section, a quick example could be qemux86-64 which looks
             like:<literallayout class="monospaced">
      "qemux86-64" : {
          "MACHINE" : "qemux86-64",
@@ -31,7 +31,7 @@
          }
      },
                     </literallayout>And
-            to expand that, you need the “arch-qemu” entry from the “templates” section, which looks
+            to expand that, you need the "arch-qemu" entry from the "templates" section, which looks
             like:<literallayout class="monospaced">
      "arch-qemu" : {
          "BUILDINFO" : true,
@@ -52,10 +52,10 @@
          }
      },
                     </literallayout>Combining
-            these two entries you can see that “qemux86-64” is a three step build where the
+            these two entries you can see that "qemux86-64" is a three step build where the
                 <filename>bitbake BBTARGETS</filename> would be run, then <filename>bitbake
                 SANITYTARGETS</filename> for each step; all for
-                <filename>MACHINE=”qemx86-64”</filename> but with differing SDKMACHINE settings. In
+                <filename>MACHINE="qemx86-64"</filename> but with differing SDKMACHINE settings. In
             step 1 an extra variable is added to the <filename>auto.conf</filename> file to enable
             wic image generation.</para>
         <para>While not every detail of this is covered here, you can see how the templating
@@ -260,7 +260,7 @@
                 <listitem>
                     <para dir="ltr">Cleanup the build directory using <link
                             linkend="test-clobberdir"><filename>clobberdir</filename></link> if the
-                        build was successful, else rename it to “build-renamed” for potential future
+                        build was successful, else rename it to "build-renamed" for potential future
                         debugging.</para>
                 </listitem>
             </orderedlist></para>