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/overview-manual/overview-manual-development-environment.rst b/documentation/overview-manual/overview-manual-development-environment.rst
index 273e1027da..3b5147d732 100644
--- a/documentation/overview-manual/overview-manual-development-environment.rst
+++ b/documentation/overview-manual/overview-manual-development-environment.rst
@@ -238,7 +238,7 @@ open source projects do so.
 
 For the Yocto Project, a key individual called the "maintainer" is
 responsible for the integrity of the "master" branch of a given Git
-repository. The "master" branch is the “upstream” repository from which
+repository. The "master" branch is the "upstream" repository from which
 final or most recent builds of a project occur. The maintainer is
 responsible for accepting changes from other developers and for
 organizing the underlying branch structure to reflect release strategies
@@ -273,19 +273,19 @@ with whatever upstream branch they are working against. They are also
 responsible for straightening out any conflicts that might arise within
 files that are being worked on simultaneously by more than one person.
 All this work is done locally on the development host before anything is
-pushed to a "contrib" area and examined at the maintainer’s level.
+pushed to a "contrib" area and examined at the maintainer's level.
 
 A somewhat formal method exists by which developers commit changes and
 push them into the "contrib" area and subsequently request that the
 maintainer include them into an upstream branch. This process is called
-“submitting a patch” or "submitting a change." For information on
+"submitting a patch" or "submitting a change." For information on
 submitting patches and changes, see the
 ":ref:`dev-manual/dev-manual-common-tasks:submitting a change to the yocto project`"
 section in the Yocto Project Development Tasks Manual.
 
 In summary, a single point of entry exists for changes into a "master"
 or development branch of the Git repository, which is controlled by the
-project’s maintainer. And, a set of developers exist who independently
+project's maintainer. And, a set of developers exist who independently
 develop, test, and submit changes to "contrib" areas for the maintainer
 to examine. The maintainer then chooses which changes are going to
 become a permanent part of the project.
@@ -526,7 +526,7 @@ descriptions and strategies on how to use these commands:
    Git commands unless you have a ``.git`` repository.
 
 -  *git clone:* Creates a local clone of a Git repository that is on
-   equal footing with a fellow developer’s Git repository or an upstream
+   equal footing with a fellow developer's Git repository or an upstream
    repository.
 
 -  *git add:* Locally stages updated file contents to the index that
@@ -537,7 +537,7 @@ descriptions and strategies on how to use these commands:
    you made. Only changes that have been staged can be committed.
    Commits are used for historical purposes, for determining if a
    maintainer of a project will allow the change, and for ultimately
-   pushing the change from your local Git repository into the project’s
+   pushing the change from your local Git repository into the project's
    upstream repository.
 
 -  *git status:* Reports any modified files that possibly need to be
diff --git a/documentation/overview-manual/overview-manual-development-environment.xml b/documentation/overview-manual/overview-manual-development-environment.xml
index 8415d1dd70..08ad071316 100644
--- a/documentation/overview-manual/overview-manual-development-environment.xml
+++ b/documentation/overview-manual/overview-manual-development-environment.xml
@@ -327,7 +327,7 @@
         For the Yocto Project, a key individual called the "maintainer" is
         responsible for the integrity of the "master" branch of a given Git
         repository.
-        The "master" branch is the “upstream” repository from which final or
+        The "master" branch is the "upstream" repository from which final or
         most recent builds of a project occur.
         The maintainer is responsible for accepting changes from other
         developers and for organizing the underlying branch structure to
@@ -372,7 +372,7 @@
         might arise within files that are being worked on simultaneously by
         more than one person.
         All this work is done locally on the development host before
-        anything is pushed to a "contrib" area and examined at the maintainer’s
+        anything is pushed to a "contrib" area and examined at the maintainer's
         level.
     </para>
 
@@ -380,7 +380,7 @@
         A somewhat formal method exists by which developers commit changes
         and push them into the "contrib" area and subsequently request that
         the maintainer include them into an upstream branch.
-        This process is called “submitting a patch” or "submitting a change."
+        This process is called "submitting a patch" or "submitting a change."
         For information on submitting patches and changes, see the
         "<ulink url='&YOCTO_DOCS_DEV_URL;#how-to-submit-a-change'>Submitting a Change to the Yocto Project</ulink>"
         section in the Yocto Project Development Tasks Manual.
@@ -389,7 +389,7 @@
     <para>
         In summary, a single point of entry
         exists for changes into a "master" or development branch of the
-        Git repository, which is controlled by the project’s maintainer.
+        Git repository, which is controlled by the project's maintainer.
         And, a set of developers exist who independently develop, test, and
         submit changes to "contrib" areas for the maintainer to examine.
         The maintainer then chooses which changes are going to become a
@@ -734,7 +734,7 @@
                 <listitem><para id='git-commands-clone'>
                     <emphasis><filename>git clone</filename>:</emphasis>
                     Creates a local clone of a Git repository that is on
-                    equal footing with a fellow developer’s Git repository
+                    equal footing with a fellow developer's Git repository
                     or an upstream repository.
                     </para></listitem>
                 <listitem><para>
@@ -752,7 +752,7 @@
                     Commits are used for historical purposes, for determining
                     if a maintainer of a project will allow the change,
                     and for ultimately pushing the change from your local
-                    Git repository into the project’s upstream repository.
+                    Git repository into the project's upstream repository.
                     </para></listitem>
                 <listitem><para>
                     <emphasis><filename>git status</filename>:</emphasis>
diff --git a/documentation/overview-manual/overview-manual-yp-intro.rst b/documentation/overview-manual/overview-manual-yp-intro.rst
index f01d9f7125..823c96d88c 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.rst
+++ b/documentation/overview-manual/overview-manual-yp-intro.rst
@@ -319,14 +319,14 @@ applications using the Yocto Project:
 
    The ``devtool`` command employs a number of sub-commands that allow
    you to add, modify, and upgrade recipes. As with the OpenEmbedded
-   build system, “recipes” represent software packages within
+   build system, "recipes" represent software packages within
    ``devtool``. When you use ``devtool add``, a recipe is automatically
    created. When you use ``devtool modify``, the specified existing
    recipe is used in order to determine where to get the source code and
    how to patch it. In both cases, an environment is set up so that when
    you build the recipe a source tree that is under your control is used
    in order to allow you to make changes to the source as desired. By
-   default, both new recipes and the source go into a “workspace”
+   default, both new recipes and the source go into a "workspace"
    directory under the eSDK. The ``devtool upgrade`` command updates an
    existing recipe so that you can build it for an updated set of source
    files.
@@ -417,7 +417,7 @@ activities using the Yocto Project:
    years ago. Both prelink and cross-prelink are maintained in the same
    repository albeit on separate branches. By providing an emulated
    runtime dynamic linker (i.e. ``glibc``-derived ``ld.so`` emulation),
-   the cross-prelink project extends the prelink software’s ability to
+   the cross-prelink project extends the prelink software's ability to
    prelink a sysroot environment. Additionally, the cross-prelink
    software enables the ability to work in sysroot style environments.
 
@@ -432,7 +432,7 @@ activities using the Yocto Project:
    library code can be re-used from shared Copy-On-Write (COW) pages.
 
    The original upstream prelink project only supports running prelink
-   on the end target device due to the reliance on the target device’s
+   on the end target device due to the reliance on the target device's
    dynamic linker. This restriction causes issues when developing a
    cross-compiled system. The cross-prelink adds a synthesized dynamic
    loader that runs on the host, thus permitting cross-prelinking
@@ -495,7 +495,7 @@ The following list consists of components associated with the
    Sharing a core set of metadata results in Poky as an integration
    layer on top of OE-Core. You can see that in this
    `figure <#yp-key-dev-elements>`__. The Yocto Project combines various
-   components such as BitBake, OE-Core, script “glue”, and documentation
+   components such as BitBake, OE-Core, script "glue", and documentation
    for its build system.
 
 .. _gs-reference-distribution-poky:
@@ -556,7 +556,7 @@ targets:
    .. note::
 
       As best it can, opkg maintains backwards compatibility with ipkg
-      and conforms to a subset of Debian’s policy manual regarding
+      and conforms to a subset of Debian's policy manual regarding
       control files.
 
 .. _gs-archived-components:
diff --git a/documentation/overview-manual/overview-manual-yp-intro.xml b/documentation/overview-manual/overview-manual-yp-intro.xml
index 2097ed36e5..a2a1f494bb 100644
--- a/documentation/overview-manual/overview-manual-yp-intro.xml
+++ b/documentation/overview-manual/overview-manual-yp-intro.xml
@@ -459,7 +459,7 @@
                         <para>The <filename>devtool</filename> command employs
                         a number of sub-commands that allow you to add, modify,
                         and upgrade recipes.
-                        As with the OpenEmbedded build system, “recipes”
+                        As with the OpenEmbedded build system, "recipes"
                         represent software packages within
                         <filename>devtool</filename>.
                         When you use <filename>devtool add</filename>, a recipe
@@ -472,7 +472,7 @@
                         control is used in order to allow you to make changes
                         to the source as desired.
                         By default, both new recipes and the source go into
-                        a “workspace” directory under the eSDK.
+                        a "workspace" directory under the eSDK.
                         The <filename>devtool upgrade</filename> command
                         updates an existing recipe so that you can build it
                         for an updated set of source files.</para>
@@ -598,7 +598,7 @@
                         By providing an emulated runtime dynamic linker
                         (i.e. <filename>glibc</filename>-derived
                         <filename>ld.so</filename> emulation), the
-                        cross-prelink project extends the prelink software’s
+                        cross-prelink project extends the prelink software's
                         ability to prelink a sysroot environment.
                         Additionally, the cross-prelink software enables the
                         ability to work in sysroot style environments.</para>
@@ -620,7 +620,7 @@
 
                         <para>The original upstream prelink project only
                         supports running prelink on the end target device
-                        due to the reliance on the target device’s dynamic
+                        due to the reliance on the target device's dynamic
                         linker.
                         This restriction causes issues when developing a
                         cross-compiled system.
@@ -713,7 +713,7 @@
                         You can see that in this
                         <link linkend='yp-key-dev-elements'>figure</link>.
                         The Yocto Project combines various components such as
-                        BitBake, OE-Core, script “glue”, and documentation
+                        BitBake, OE-Core, script "glue", and documentation
                         for its build system.
                         </para></listitem>
                 </itemizedlist>
@@ -791,7 +791,7 @@
                         <note>
                             As best it can, opkg maintains backwards
                             compatibility with ipkg and conforms to a subset
-                            of Debian’s policy manual regarding control files.
+                            of Debian's policy manual regarding control files.
                         </note>
                         </para></listitem>
                 </itemizedlist>