RS: Fixed quote characters (#2080)

* DOC-5682 RS: Fixed quote characters

* DOC-5682 RS: Fixed quote characters in RS embeds

Author: rrelledge

content/embeds/json-active-active-conflict-resolution.md

@@ -45,7 +45,7 @@ The instance with the smaller ID wins, so the key becomes an object in the given
 | Time  | Description | Instance 1 | Instance 2 |
 | :---: | :--- | :--- | :--- |
 | t1 | Set the same key to an object or an array | JSON.SET doc $.a '{}' | JSON.SET doc $.a '[]' |
-| t2 | Add data to the object and array | <nobr>JSON.SET doc  $.a.x '“y”'</nobr> <br /><br /> Result: <br /> {"a": {"x": "y"}} | <nobr>JSON.SET doc $.a '["z"]'</nobr> <br /><br /> Result: <br /> {“a”: ["z"]} |
+| t2 | Add data to the object and array | <nobr>JSON.SET doc  $.a.x '"y"'</nobr> <br /><br /> Result: <br /> {"a": {"x": "y"}} | <nobr>JSON.SET doc $.a '["z"]'</nobr> <br /><br /> Result: <br /> {"a": ["z"]} |
 | t3 | Active-Active synchronization | – Sync – | – Sync – |
 | t4 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> {"a": {"x": "y"}} | JSON.GET doc $ <br /><br /> Result: <br /> {"a": {"x": "y"}} |
 
@@ -267,8 +267,8 @@ Merges the results of all operations on the array. Preserves the original elemen
 | Time  | Description | Instance 1 | Instance 2 |
 | :---: | :--- | :--- | :--- |
 | t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> '["a", "b", "c"]' | JSON.GET doc $ <br /><br /> Result: <br /> '["a", "b", "c"]' |
-| t2 | Instance 1 removes an array element; instance 2 adds one | JSON.ARRPOP doc $ 1 <br /><br /> Result: <br /> ["a", "c"] | <nobr>JSON.ARRINSERT doc $ 0 ‘“y”’</nobr> <br /><br /> Result: <br /> ["y", "a", "b", "c"] |
-| t3 | Both instances add another element to the array | <nobr>JSON.ARRINSERT doc $ 1 ‘“x”’</nobr> <br /><br /> Result: <br /> ["a", "x", "c"] | <nobr>JSON.ARRINSERT doc $ 2 ‘“z”’</nobr> <br /><br /> Result: <br /> ["y", "a", "z", "b", "c"] |
+| t2 | Instance 1 removes an array element; instance 2 adds one | JSON.ARRPOP doc $ 1 <br /><br /> Result: <br /> ["a", "c"] | <nobr>JSON.ARRINSERT doc $ 0 ‘"y"’</nobr> <br /><br /> Result: <br /> ["y", "a", "b", "c"] |
+| t3 | Both instances add another element to the array | <nobr>JSON.ARRINSERT doc $ 1 ‘"x"’</nobr> <br /><br /> Result: <br /> ["a", "x", "c"] | <nobr>JSON.ARRINSERT doc $ 2 ‘"z"’</nobr> <br /><br /> Result: <br /> ["y", "a", "z", "b", "c"] |
 | t4 | Active-Active synchronization | – Sync – | – Sync – |
 | t5 | Merge results from both instances | JSON.GET doc $ <br /><br /> Result: <br /> ["y", "a", "x", "z", "c"] | JSON.GET doc $ <br /><br /> Result: <br /> ["y", "a", "x", "z", "c"] |
 
@@ -292,11 +292,11 @@ Deletion wins over updates.
 
 | Time  | Description | Instance 1 | Instance 2 |
 | :---: | :--- | :--- | :--- |
-| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: [{“title”: “buy milk”, “done”: false}]} | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: [{“title”: “buy milk”, “done”: false}]} |
+| t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> {"todo": [{"title": "buy milk", "done": false}]} | JSON.GET doc $ <br /><br /> Result: <br /> {"todo": [{"title": "buy milk", "done": false}]} |
 | t2 | Instance 1 removes an array element; instance 2 updates the same element | <nobr>JSON.ARRPOP doc $.todo 0</nobr> | <nobr>JSON.SET doc '$.todo[0]["done"]' 'true'’</nobr> |
-| t3 |  | JSON.GET doc $ <br /><br /> Result: <br /> {“todo”: []} | JSON.GET doc $ <br /><br /> Result: <br /> [{“title”: “buy milk”, “done”: true}]} |
+| t3 |  | JSON.GET doc $ <br /><br /> Result: <br /> {"todo": []} | JSON.GET doc $ <br /><br /> Result: <br /> [{"title": "buy milk", "done": true}]} |
 | t4 | Active-Active synchronization | – Sync – | – Sync – |
-| t5 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> doc = {“todo”: []} | JSON.GET doc $ <br /><br /> Result: <br /> doc = {“todo”: []} |
+| t5 | Instance 1 wins | JSON.GET doc $ <br /><br /> Result: <br /> doc = {"todo": []} | JSON.GET doc $ <br /><br /> Result: <br /> doc = {"todo": []} |
 
 ### Update versus update object
 
@@ -317,8 +317,8 @@ Merges the results of all operations on the object.
 | Time  | Description | Instance 1 | Instance 2 |
 | :---: | :--- | :--- | :--- |
 | t1 | The document exists on both instances | JSON.GET doc $ <br /><br /> Result: <br /> '{"grocery": []}' | JSON.GET doc $ <br /><br /> Result: <br /> '{"grocery": []}' |
-| t2 | Add new elements to the array | <nobr>JSON.ARRAPPEND doc $.grocery ‘“eggs”’</nobr> | JSON.ARRAPPEND doc $.grocery ‘“milk”’ |
-| t3 | Add new elements to the array | JSON.ARRAPPEND doc $.grocery ‘“ham”’ | <nobr>JSON.ARRAPPEND doc $.grocery ‘“flour”’</nobr> |
+| t2 | Add new elements to the array | <nobr>JSON.ARRAPPEND doc $.grocery ‘"eggs"’</nobr> | JSON.ARRAPPEND doc $.grocery ‘"milk"’ |
+| t3 | Add new elements to the array | JSON.ARRAPPEND doc $.grocery ‘"ham"’ | <nobr>JSON.ARRAPPEND doc $.grocery ‘"flour"’</nobr> |
 | t4 |  | JSON.GET doc $ <br /><br /> Result: <br /> {"grocery":["eggs", "ham"]} | JSON.GET doc $ <br /><br /> Result: <br /> {"grocery":["milk", "flour"]} |
 | t5 | Active-Active synchronization | – Sync – | – Sync – |
 | t6 | Merges the results from both instances | JSON.GET doc . <br /><br /> Result: <br /> {"grocery":["eggs","ham","milk", "flour"]} | JSON.GET doc . <br /><br /> Result: <br /> {"grocery":["eggs","ham","milk", "flour" ]} |

content/embeds/rs-observability.md

@@ -278,7 +278,7 @@ Dashboard displaying connection metrics between zones - [Synchronization Dashboa
 CRDT provides three fundamental benefits over other geo-distributed solutions:
 
 * It offers local latency on read and write operations, regardless of the number of geo-replicated regions and their distance from each other.
-* It enables seamless conflict resolution (“conflict-free”) for simple and complex data types like those of Redis core.
+* It enables seamless conflict resolution ("conflict-free") for simple and complex data types like those of Redis core.
 * Even if most of the geo-replicated regions in a CRDT database (for example, 3 out of 5) are down, the remaining geo-replicated regions are uninterrupted and can continue to handle read and write operations, ensuring business continuity.
 
 ## Database performance indicators

content/operate/rs/7.4/databases/active-active/develop/_index.md

@@ -56,12 +56,12 @@ in between.
 
 |  **Time** | **CRDB Instance1** | **CRDB Instance2** |
 |  ------: | :------: | :------: |
-|  t1 | SET key1 “a” |  |
-|  t2 |  | SET key1 “b” |
+|  t1 | SET key1 "a" |  |
+|  t2 |  | SET key1 "b" |
 |  t3 | — Sync — | — Sync — |
-|  t4 | SET key1 “c” |  |
+|  t4 | SET key1 "c" |  |
 |  t5 | — Sync — | — Sync — |
-|  t6 |  | SET key1 “d” |
+|  t6 |  | SET key1 "d" |
 
 [Learn more about
 synchronization for

content/operate/rs/7.4/databases/active-active/develop/data-types/hashes.md

@@ -37,7 +37,7 @@ Here is an example of an "add wins" case:
 
 |  **Time** | **CRDB Instance1** | **CRDB Instance2** |
 |  ------: | :------: | :------: |
-|  t1 | HSET key1 field1 “a” |  |
-|  t2 |  | HSET key1 field2 “b” |
+|  t1 | HSET key1 field1 "a" |  |
+|  t2 |  | HSET key1 field2 "b" |
 |  t4 | - Sync - | - Sync - |
-|  t5 | HGETALL key1<br/>1) “field2”<br/>2) “b”<br/>3) “field1”<br/>4) “a” | HGETALL key1<br/>1) “field2”<br/>2) “b”<br/>3) “field1”<br/>4) “a” |
+|  t5 | HGETALL key1<br/>1) "field2"<br/>2) "b"<br/>3) "field1"<br/>4) "a" | HGETALL key1<br/>1) "field2"<br/>2) "b"<br/>3) "field1"<br/>4) "a" |

content/operate/rs/7.4/databases/active-active/develop/data-types/lists.md

@@ -27,11 +27,11 @@ example:
 
 |  **Time** | **CRDB Instance 1** | **CRDB Instance 2** |
 |  ------: | :------: | :------: |
-|  t1 | LPUSH mylist “hello” |  |
+|  t1 | LPUSH mylist "hello" |  |
 |  t2 | — Sync — | — Sync — |
-|  t3 |  | LPUSH mylist “world” |
+|  t3 |  | LPUSH mylist "world" |
 |  t4 | — Sync — | — Sync — |
-|  t5 | LRANGE mylist 0 -1 =>“world” “hello” | LRANGE mylist 0 -1 => “world” “hello” |
+|  t5 | LRANGE mylist 0 -1 =>"world" "hello" | LRANGE mylist 0 -1 => "world" "hello" |
 
 **Explanation**:
 The final list contains both the "world" and "hello" elements, in that

content/operate/rs/7.4/databases/active-active/develop/data-types/sets.md

@@ -31,18 +31,18 @@ Here is an example of an "add wins" case:
 
 |  **Time** | **CRDB Instance1** | **CRDB Instance2** |
 |  ------: | :------: | :------: |
-|  t1 | SADD key1 “a” |  |
-|  t2 |  | SADD key1 “b” |
-|  t3 | SMEMBERS key1 “a” | SMEMBERS key1 “b” |
+|  t1 | SADD key1 "a" |  |
+|  t2 |  | SADD key1 "b" |
+|  t3 | SMEMBERS key1 "a" | SMEMBERS key1 "b" |
 |  t4 | — Sync — | — Sync — |
-|  t3 | SMEMBERS key1 “a” “b” | SMEMBERS key1 “a” “b” |
+|  t3 | SMEMBERS key1 "a" "b" | SMEMBERS key1 "a" "b" |
 
 Here is an example of an "observed remove" case.
 
 |  **Time** | **CRDB Instance1** | **CRDB Instance2** |
 |  ------: | :------: | :------: |
-|  t1 | SMEMBERS key1 “a” “b” | SMEMBERS key1 “a” “b” |
-|  t2 | SREM key1 “a” | SADD key1 “c” |
-|  t3 | SREM key1 “c” |  |
+|  t1 | SMEMBERS key1 "a" "b" | SMEMBERS key1 "a" "b" |
+|  t2 | SREM key1 "a" | SADD key1 "c" |
+|  t3 | SREM key1 "c" |  |
 |  t4 | — Sync — | — Sync — |
-|  t3 | SMEMBERS key1 “c” “b” | SMEMBERS key1 “c” “b” |
+|  t3 | SMEMBERS key1 "c" "b" | SMEMBERS key1 "c" "b" |

content/operate/rs/7.4/databases/active-active/develop/data-types/strings.md

@@ -34,12 +34,12 @@ time (t2) wins over the update at t1.
 
 |  **Time** | **Region 1** | **Region 2** |
 |  :------: | :------: | :------: |
-|  t1 | SET text “a” |  |
-|  t2 |  | SET text “b” |
+|  t1 | SET text "a" |  |
+|  t2 |  | SET text "b" |
 |  t3 | — Sync — | — Sync — |
-|  t4 | SET text “c” |  |
+|  t4 | SET text "c" |  |
 |  t5 | — Sync — | — Sync — |
-|  t6 |  | SET text “d” |
+|  t6 |  | SET text "d" |
 
 ### String counter support
 

content/operate/rs/7.4/databases/auto-tiering/_index.md

@@ -53,9 +53,9 @@ When using Auto Tiering, RAM storage holds:
 - Dictionaries
 - Hot data (working set)
 
-All data is accessed through RAM. If a value in flash memory is accessed, it becomes part of the working set and is moved to RAM. These values are referred to as “hot data”.
+All data is accessed through RAM. If a value in flash memory is accessed, it becomes part of the working set and is moved to RAM. These values are referred to as "hot data".
 
-Inactive or infrequently accessed data is referred to as “warm data” and stored in flash memory. When more space is needed in RAM, warm data is moved from RAM to flash storage.
+Inactive or infrequently accessed data is referred to as "warm data" and stored in flash memory. When more space is needed in RAM, warm data is moved from RAM to flash storage.
 
 {{<note>}} When using Auto Tiering with RediSearch, it’s important to note that RediSearch indexes are also stored in RAM.{{</note>}}
 

content/operate/rs/7.4/installing-upgrading/product-lifecycle.md

@@ -19,7 +19,7 @@ Redis Enterprise modules follow the [modules lifecycle]({{< relref "/operate/oss
 ## Release numbers
 
 Redis uses a four-place numbering scheme to designate released versions of its products.
-The format is “Major1.Major2.Minor-Build”.
+The format is "Major1.Major2.Minor-Build".
 
 - Major sections of the version number represents fundamental changes and additions in
     capabilities to Redis  Enterprise Software. The Major1 and Major2 part of the

content/operate/rs/7.4/networking/cluster-lba-setup.md

@@ -44,7 +44,7 @@ The architecture is shown in the following diagram with a 3-node Redis Enterpris
 - [Install]({{< relref "/operate/rs/7.4/installing-upgrading" >}}) the latest version of Redis Enterprise Software on your clusters
 - Configure the cluster with the cluster name (FQDN) even though DNS is not in use.
     Remember that the same cluster name is used to issue the license keys.
-    We recommend that you use a “.local” suffix in the FQDN.
+    We recommend that you use a ".local" suffix in the FQDN.
 
 ### Configure load balancers