From b51294dc3df5260857d260fdc3c56c85ac8c6766 Mon Sep 17 00:00:00 2001
From: gaofei <gao.fei@inspur.com>
Date: Tue, 23 Jan 2018 16:31:43 +0800
Subject: [PATCH] Replace Chinese punctuation with English punctuation

Change-Id: Icc4a984e8defe4d068e7f4a78cd5483a0cb9c7b7
---
 doc/source/user/multinode.rst | 2 +-
 specs/logging-with-heka.rst   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/doc/source/user/multinode.rst b/doc/source/user/multinode.rst
index f051b5e87c..5ad33bc17f 100644
--- a/doc/source/user/multinode.rst
+++ b/doc/source/user/multinode.rst
@@ -209,7 +209,7 @@ to them:
 
 .. note::
 
-   RabbitMQ doesn’t work with IP addresses, hence the IP address of
+   RabbitMQ doesn't work with IP addresses, hence the IP address of
    ``api_interface`` should be resolvable by hostnames to make sure that all
    RabbitMQ Cluster hosts can resolve each others hostnames beforehand.
 
diff --git a/specs/logging-with-heka.rst b/specs/logging-with-heka.rst
index 17ba4b3eb9..7cd7770b31 100644
--- a/specs/logging-with-heka.rst
+++ b/specs/logging-with-heka.rst
@@ -62,7 +62,7 @@ run it on every node of the cluster. In contrast, Logstash runs in a JVM and
 is known [3] to be too heavy to run on every node.
 
 Another important aspect is flow control and avoiding the loss of log messages
-in case of overload. Heka’s filter and output plugins, and the Elasticsearch
+in case of overload. Heka's filter and output plugins, and the Elasticsearch
 output plugin in particular, support the use of a disk based message queue.
 This message queue allows plugins to reprocess messages from the queue when
 downstream servers (Elasticsearch) are down or cannot keep up with the data