Add a code-smell test for smart quotes and remove smart quotes from all files

docs/docsite/rst/dev_guide/developing_modules_checklist.rst

@@ -55,7 +55,7 @@ The complete module metadata specification is here: `Ansible metadata block <htt
     * Examples--include them whenever possible and make sure they are reproducible.
     * Document the return structure of the module. Refer to :ref:`common_return_values` and :ref:`module_documenting` for additional information.
 * Predictable user interface: This is a particularly important section as it is also an area where we need significant improvements.
-    * Name consistency across modules (we’ve gotten better at this, but we still have many deviations).
+    * Name consistency across modules (we've gotten better at this, but we still have many deviations).
     * Declarative operation (not CRUD)--this makes it easy for a user not to care what the existing state is, just about the final state. ``started/stopped``, ``present/absent``--don't overload options too much. It is preferable to add a new, simple option than to add choices/states that don't fit with existing ones.
     * Keep options small, having them take large data structures might save us a few tasks, but adds a complex requirement that we cannot easily validate before passing on to the module.
     * Allow an "expert mode". This may sound like the absolute opposite of the previous one, but it is always best to let expert users deal with complex data. This requires different modules in some cases, so that you end up having one (1) expert module and several 'piecemeal' ones (ec2_vpc_net?). The reason for this is not, as many users express, because it allows a single task and keeps plays small (which just moves the data complexity into vars files, leaving you with a slightly different structure in another YAML file). It does, however, allow for a more 'atomic' operation against the underlying APIs and services.

docs/docsite/rst/dev_guide/developing_modules_documenting.rst

@@ -109,11 +109,11 @@ Structure
 Fields
 ^^^^^^
 
-:metadata_version: An “X.Y” formatted string. X and Y are integers which
+:metadata_version: An "X.Y" formatted string. X and Y are integers which
    define the metadata format version. Modules shipped with Ansible are
    tied to an Ansible release, so we will only ship with a single version
-   of the metadata. We’ll increment Y if we add fields or legal values
-   to an existing field. We’ll increment X if we remove fields or values
+   of the metadata. We'll increment Y if we add fields or legal values
+   to an existing field. We'll increment X if we remove fields or values
    or change the type or meaning of a field.
    Current metadata_version is "1.1"
 :supported_by: This field records who supports the module.
@@ -130,13 +130,13 @@ Fields
    `Modules Support <http://docs.ansible.com/ansible/modules_support.html>`_.
 
 :status: This field records information about the module that is
-   important to the end user. It’s a list of strings. The default value
-   is a single element list [“preview”]. The following strings are valid
+   important to the end user. It's a list of strings. The default value
+   is a single element list ["preview"]. The following strings are valid
    statuses and have the following meanings:
 
-   :stableinterface: This means that the module’s parameters are
+   :stableinterface: This means that the module's parameters are
       stable. Every effort will be made not to remove parameters or change
-      their meaning. It is not a rating of the module’s code quality.
+      their meaning. It is not a rating of the module's code quality.
    :preview: This module is a tech preview. This means it may be
       unstable, the parameters may change, or it may require libraries or
       web services that are themselves subject to incompatible changes.

docs/docsite/rst/dev_guide/overview_architecture.rst

@@ -25,7 +25,7 @@ Inventory
 
 By default, Ansible represents what machines it manages using a very simple INI file that puts all of your managed machines in groups of your own choosing.
 
-To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn’t get linked up due to obscure NTP or DNS issues.
+To add new machines, there is no additional SSL signing server involved, so there's never any hassle deciding why a particular machine didn't get linked up due to obscure NTP or DNS issues.
 
 If there's another source of truth in your infrastructure, Ansible can also plugin to that, such as drawing inventory, group, and variable information from sources like EC2, Rackspace, OpenStack, and more.
 
@@ -69,4 +69,4 @@ Here's what a simple playbook looks like::
 Extending Ansible with Plug-ins and the API
 ````````````````````````````````````````````
 
-Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible’s connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.
+Should you want to write your own, Ansible modules can be written in any language that can return JSON (Ruby, Python, bash, etc). Inventory can also plug in to any datasource by writing a program that speaks to that datasource and returns JSON. There's also various Python APIs for extending Ansible's connection types (SSH is not the only transport possible), callbacks (how Ansible logs, etc), and even for adding new server side behaviors.

docs/docsite/rst/dev_guide/style_guide/grammar_punctuation.rst

@@ -110,7 +110,7 @@ Never use "we" when writing. "We" aren't doing anything on the user side. Ansibl
 
 Hyphen
 ~~~~~~~~~~~~~~
-The hyphen’s primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary.
+The hyphen's primary function is the formation of certain compound terms. Do not use a hyphen unless it serves a purpose. If a compound adjective cannot be misread or, as with many psychological terms, its meaning is established, a hyphen is not necessary.
 
 Use hyphens to avoid ambiguity or confusion:
 

docs/docsite/rst/dev_guide/style_guide/spelling_word_choice.rst

@@ -78,7 +78,7 @@ Use to describes where to place options for a command, but not where to type the
 Daylight saving time (DST)
 +++++++++++++++++++++++++++++++
 
-Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled “Daylight Savings”, with an “s” at the end. Other common variations are “Summer Time”and “Daylight-Saving Time”. (http://www.timeanddate.com/time/dst/daylight-savings-time.html)
+Correct. Do not use daylight savings time. Daylight Saving Time (DST) is often misspelled "Daylight Savings", with an "s" at the end. Other common variations are "Summer Time"and "Daylight-Saving Time". (http://www.timeanddate.com/time/dst/daylight-savings-time.html)
 
 
 Download
@@ -99,7 +99,7 @@ When used as a verb, fail over is two words since there can be different tenses
 
 Fewer
 +++++++++++++++++++
-Fewer is used with plural nouns. Think things you could count.  Time, money, distance, and weight are often listed as exceptions to the traditional “can you count it” rule, often thought of a singular amounts (the work will take less than 5 hours, for example).
+Fewer is used with plural nouns. Think things you could count.  Time, money, distance, and weight are often listed as exceptions to the traditional "can you count it" rule, often thought of a singular amounts (the work will take less than 5 hours, for example).
 
 File name
 +++++++++++++

docs/docsite/rst/dev_guide/style_guide/why_use.rst

@@ -13,8 +13,8 @@ This style guide incorporates current Ansible resources and information so that
 
    <blockquote class="note info">
 
-   “If you don't find it in the index, look very carefully through the entire catalogue.” 
-    ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue 
+   "If you don't find it in the index, look very carefully through the entire catalogue."
+    ― Sears, Roebuck and Co., 1897 Sears Roebuck & Co. Catalogue
  
 .. raw:: html
 

docs/docsite/rst/dev_guide/testing/sanity/no-smart-quotes.rst

@@ -0,0 +1,4 @@
+Sanity Tests » no-smart-quotes
+==============================
+
+Smart quotes (``”“‘’``) should not be used.  Use plain ascii quotes (``"'``) instead.