(Probably) final changes, remove hyphens

src/content/doc-surrealdb/integration/rpc.mdx

@@ -2,7 +2,7 @@
 sidebar_position: 4
 sidebar_label: RPC Protocol
 title: RPC Protocol | Integration
-description: The RPC protocol allows for easy bi-directional communication with SurrealDB.
+description: The RPC protocol allows for easy bidirectional communication with SurrealDB.
 ---
 
 import Since from '@components/shared/Since.astro'

src/content/doc-surrealdb/introduction/mongo.mdx

@@ -100,7 +100,7 @@ For more in-depth explanations of SurrealDB concepts, see the [concepts page](/d
                 reference and embedding
             </td>
             <td colspan="2" scope="row" data-label="SurrealDB">
-                record links, embedding and  graph relations
+                record links, embedding and graph relations
             </td>
         </tr>
     </tbody>

src/content/doc-surrealdb/introduction/sql.mdx

@@ -86,7 +86,7 @@ For more in-depth explanations of SurrealDB concepts, see the [concepts page](/d
                 join
             </td>
             <td colspan="2" scope="row" data-label="SurrealDB">
-                record links, embedding and  graph relations
+                record links, embedding and graph relations
             </td>
         </tr>
     </tbody>

src/content/doc-surrealql/datamodel/records.mdx

@@ -88,7 +88,7 @@ SELECT friends.friends.friends.name FROM person:tobie;
 
 ## Next steps
 
-You've now seen how to create records using randomly generated ids, or specific record ids. This is just the beginning! The power and flexibility which is possible with the remote record fetching functionality within queries opens up a whole new set of possibilities for storing and querying traditional data, and connected datasets. Take a look at the next chapter to understand how futures can be used to dynamically compute values only when retrieved.
+You've now seen how to create records using randomly generated ids, or specific record ids. This is just the beginning! The power and flexibility which is possible with the remote record fetching functionality within queries opens up a whole new set of possibilities for storing and querying traditional data, and connected datasets. The next page follows up with a feature available in SurrealDB since version 2.2.0: the ability to use record links in a bidirectional manner thanks to reference tracking.
 
 Also check out this explainer video on using record links in SurrealDB:
 

src/content/doc-surrealql/statements/define/indexes.mdx

@@ -32,6 +32,7 @@ DEFINE INDEX [ OVERWRITE | IF NOT EXISTS ] @name ON [ TABLE ] @table [ FIELDS |
 ```
 
 ## Index Types
+
 SurrealDB offers a range of indexing capabilities designed to optimize data retrieval and search efficiency.
 
 ### Unique Index
@@ -108,6 +109,7 @@ CREATE user:2 SET email = '[email protected]'
 ```
 
 ### Non-Unique Index
+
 This allows for the indexing of attributes that may have non-unique values, facilitating efficient data retrieval. Non-unique indexes help index frequently appearing data in queries that do not require uniqueness, such as categorization tags or status indicators.
 
 Let's create a non-unique index for an age field on a user table.
@@ -240,7 +242,7 @@ url="https://surrealist.app/mini?query=CREATE+pts%3A3+SET+point+%3D+%5B8%2C9%2C1
 In the example above, you may notice the `EFC` and `M` parameters. These are optional to your query but are parameters of the [HNSW algorithm](https://arxiv.org/abs/1603.09320) and can be used to tune the index for better performance. At a glance
 
 - M (Max Connections per Element):
-Defines the maximum number of bi-directional links (neighbors) per node in each layer of the graph, except for the lowest layer. This parameter controls the connectivity and overall structure of the network. Higher values of MM generally improve search accuracy but increase memory usage and construction time.
+Defines the maximum number of bidirectional links (neighbors) per node in each layer of the graph, except for the lowest layer. This parameter controls the connectivity and overall structure of the network. Higher values of MM generally improve search accuracy but increase memory usage and construction time.
 
 - EFC (EF construction):
 Stands for "exploration factor during construction." This parameter determines the size of the dynamic list for the nearest neighbor candidates during the graph construction phase. A larger efConstruction value leads to a more thorough construction, improving the quality and accuracy of the search but increasing construction time. The default value is 150.

src/content/doc-surrealql/statements/relate.mdx

@@ -17,13 +17,13 @@ Edges created using the RELATE statement are nearly identical to tables created
 
 Otherwise, edge tables behave like normal tables in terms of [updating](/docs/surrealql/statements/update), [defining a schema](/docs/surrealql/statements/define/table) or [indexes](/docs/surrealql/statements/define/indexes).
 
-Another option for connecting data is using [record links](/docs/surrealql/datamodel/records). Record links consist of a field with record IDs that serve as uni-directional links. The key differences are that graph relations have the following benefits over record links:
+Another option for connecting data is using [record links](/docs/surrealql/datamodel/records). Record links consist of a field with record IDs that serve as unidirectional links by default, or bidirectional links if reference tracking is used. The key differences are that graph relations have the following benefits over record links:
 
 - Graph relations are kept in a separate table as opposed to a field inside a record.
-- Graph relations you to store data alongside the relationship.
+- Graph relations allow you to store data alongside the relationship.
 - Graph relations have their own syntax that makes it easy to build and visualize edge queries.
 
-Graph relations also offer built-in bi-directional querying and referential integrity. As of SurrealDB 2.2.0, record links also offer these two advantages if they are defined inside a [`DEFINE FIELD`](/docs/surrealql/statements/define/field) statement using the `REFERENCES` clause. For more information, see [the page on record references](/docs/surrealql/datamodel/references).
+Graph relations offer built-in bidirectional querying and referential integrity. As of SurrealDB 2.2.0, record links also offer these two advantages if they are defined inside a [`DEFINE FIELD`](/docs/surrealql/statements/define/field) statement using the `REFERENCES` clause. For more information, see [the page on record references](/docs/surrealql/datamodel/references).
 
 ### Statement syntax
 
@@ -140,7 +140,7 @@ DEFINE INDEX unique_relationships
     COLUMNS in, out UNIQUE;
 ```
 
-As edge tables are bi-directional by default, there is nothing stopping a query like the following in which an article writes a person instead of the other way around.
+As edge tables are bidirectional by default, there is nothing stopping a query like the following in which an article writes a person instead of the other way around.
 
 ```surql
 RELATE article:on_sleep_and_sleeplessness->wrote->person:aristotle;

src/content/doc-surrealql/statements/select.mdx

@@ -521,7 +521,7 @@ SELECT * FROM ONLY person WHERE name = "Jaime" LIMIT 1;
 
 ## Connect targets using the FETCH clause
 
-One of the most powerful functions in SurrealDB are the [record links](/docs/surrealql/datamodel/records) and [graph connections](/docs/surrealql/statements/relate).
+Two of the most powerful features in SurrealDB are [record links](/docs/surrealql/datamodel/records) and [graph connections](/docs/surrealql/statements/relate).
 
 Instead of pulling data from multiple tables and merging that data together, SurrealDB allows you to traverse related records efficiently without needing to use JOINs.