RC: check and update Unicode quotes to ASCII

content/operate/rc/cloud-integrations/gcp-marketplace/team-management.md

@@ -25,7 +25,7 @@ To grant Redis Cloud access to a Google Cloud user, select **Add** to add a memb
 If these roles are not available, you can add them to your project.
 
 1. Select **Manage Roles**.
-2. Use the filter table field to locate the role. (Search for “service usage viewer” or “Redis Cloud admin”.)
+2. Use the filter table field to locate the role. (Search for "service usage viewer" or "Redis Cloud admin".)
 3. Select the role.
 4. Select **Create role from selection** and then select **Create**.
 5. Use IAM to add a member and assign the desired role.

content/operate/rc/databases/configuration/clustering.md

@@ -121,14 +121,14 @@ The Standard hashing policy is mostly consistent with the Redis hashing policy,
 1. Keys without a hashtag: when a key doesn't contain the '{...}' pattern, the entire key's name is used for hashing
 
 In some cases, the Standard hashing policy behaves differently from the Redis hashing policy:
-1. Using empty hashtags (“{}”): the Standard hashing policy does not ignore empty hashtags, so two keys that start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them). 
+1. Using empty hashtags ("{}"): the Standard hashing policy does not ignore empty hashtags, so two keys that start with empty hashtags will be hashed to the same hashslot (while the Redis hashing policy would ignore them). 
     For example: given 2 keys {}foo and {}bar, hashing would be:
     - Standard hashing policy: to the same hash slot
     - Redis hashing policy: to different hash slots
 2. Using multiple curly brackets: when a key’s name contains multiple curly brackets, the Standard hashing calculation might be different than the Redis hashing policy. 
     For example: given 2 keys {foo}bar} and {foo}qux}:
-    - Standard hashing policy: substrings “foo}bar” and “foo}qux” will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.
-    - Redis hashing policy: the substring “foo” will be used for both keys, hashing them to the same slot.
+    - Standard hashing policy: substrings "foo}bar" and "foo}qux" will be used for the 1st and 2nd key respectively, hashed each key to a different hash-slot.
+    - Redis hashing policy: the substring "foo" will be used for both keys, hashing them to the same slot.
 
 {{< note >}}
 To allow seamless transition between hashing policies, the following techniques are not recommended:

content/operate/rc/databases/create-database/create-flex-database.md

@@ -44,9 +44,9 @@ When using Redis Flex, 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.
 
 ## Create a Redis Flex database on Redis Cloud Essentials