Update vocabulary for consistency

content/_index.md

@@ -29,7 +29,7 @@ This documentation follows the [Diátaxis](https://diataxis.fr) approach and str
 
 ### Table of contents
 
-- **Analysis:** guidance on how to analyze terms changes, from navigating through the history of tracked documents to publishing memos about significant changes.
+- **Analysis:** guidance on how to analyze terms changes, from navigating through the history of tracked terms to publishing memos about significant changes.
 - **Community:** information on how to participate in the Open Terms Archive community.
 - **Terms:** guidance on tracking and maintaining terms declarations.
 - **Collections:** guidance on creating and managing collections of tracked terms.

content/analysis/how-to/navigate-history.md

@@ -48,7 +48,7 @@ For this guide, we will use the example of the Demo collection. The terms of thi
 
 ### Notes
 
-- For long documents, unchanged paragraphs will not be displayed by default. You can manually make them appear by clicking on the small arrows just above or just below the displayed paragraphs:
+- For long terms, unchanged paragraphs will not be displayed by default. You can manually make them appear by clicking on the small arrows just above or just below the displayed paragraphs:
 
   ![Expand unchanged paragraphs on source diff view](/images/navigate-history/expand-source.png)  
 

content/api/cli.md

@@ -10,7 +10,7 @@ Once the engine module is installed as a dependency within another module, the `
 In these commands:
 
 - `<service_id>` is the case sensitive name of the service declaration file without the extension. For example, for `Twitter.json`, the service ID is `Twitter`.
-- `<terms_type>` is the property name used under the `documents` property in the declaration to declare a terms. For example, in the getting started declaration, the terms type declared is `Privacy Policy`.
+- `<terms_type>` is the property name used under the `terms` property in the declaration to declare a terms. For example, in the getting started declaration, the terms type declared is `Privacy Policy`.
 
 ## Tracking terms
 

content/collections/how-to/create-repositories.md

@@ -7,8 +7,8 @@ weight: 1
 
 Collections in Open Terms Archive rely on three Git repositories to hold the data:
 - Declarations repository: stores the declarations that define terms to track
-- Snapshots repository: stores raw snapshots of tracked documents
-- Versions repository: stores processed versions of tracked documents
+- Snapshots repository: stores raw snapshots of tracked terms
+- Versions repository: stores processed versions of tracked terms
 
 This guide assumes you use GitHub. For other Git platforms, adapt these steps accordingly.
 
@@ -69,7 +69,7 @@ Before starting, ensure you have:
 ### Configure repository
 
 1. Set up "About" section:
-   - Add description: "Documents snapshots for `<collection_name>`. Maintained by `<maintainer>`."
+   - Add description: "Terms snapshots for `<collection_name>`. Maintained by `<maintainer>`."
    - Set website: `https://opentermsarchive.org`
    - Add standard tags
    - Uncheck "Releases", "Packages" and "Deployments"

content/collections/tutorials/create.md

@@ -42,7 +42,7 @@ By the end, you'll have a working collection that tracks changes to a service's
     ```json
     {
       "name": "Open Terms Archive",
-      "documents": {
+      "terms": {
         "Privacy Policy": {
           "fetch": "https://opentermsarchive.org/en/privacy-policy",
           "select": ".textcontent"

content/concepts/main.md

@@ -46,7 +46,7 @@ A **declaration** also contains some metadata on the **service** on which the **
 > ```json
 > {
 >   "name": "Open Terms Archive",
->   "documents": {
+>   "terms": {
 >     "Privacy Policy": {
 >       "fetch": "https://opentermsarchive.org/en/privacy-policy",
 >       "select": ".textcontent"

content/terms/guidelines/targeting.md

@@ -9,4 +9,4 @@ aliases: /guidelines/targeting/
 
 Yes.
 
-For example, documents that would start applying at date in the future are legitimate candidates for tracking. You can this way track if their terms change even before they are applied.
+For example, terms that would start applying at date in the future are legitimate candidates for tracking. You can this way track if their terms change even before they are applied.

content/terms/how-to/rename-a-service.md

@@ -5,4 +5,4 @@ linkTitle: Rename a service
 
 # How to rename a service
 
-The consensus is to consider that a service provider renaming a service (for example, `Twitter` to `X`) is akin to terminating the previous service and opening a new one. Therefore, to apply a service renaming, open a pull request that both [terminates the previous service](#how-to-terminate-a-service) and adds a new [service declaration]({{< relref "terms/how-to/track-new-terms#declaring-a-new-service" >}}) with the new service name. You can reuse the `documents` part of the original declaration, but should double-check that the selectors and URLs still match, as a service rename is most often accompanied by a new page layout, a new domain name, and sometimes entirely new terms.
+The consensus is to consider that a service provider renaming a service (for example, `Twitter` to `X`) is akin to terminating the previous service and opening a new one. Therefore, to apply a service renaming, open a pull request that both [terminates the previous service](#how-to-terminate-a-service) and adds a new [service declaration]({{< relref "terms/how-to/track-new-terms#declaring-a-new-service" >}}) with the new service name. You can reuse the `terms` part of the original declaration, but should double-check that the selectors and URLs still match, as a service rename is most often accompanied by a new page layout, a new domain name, and sometimes entirely new terms.

content/terms/how-to/terminate-a-service.md

@@ -7,12 +7,12 @@ linkTitle: Terminate a service
 
 If the service provider stops offering a service, the associated terms will become unavailable. To mark that service termination in Open Terms Archive and ensure tracking tentatives are stopped, while maintaining the possibility to explore the history:
 
-1. Move the existing documents declaration to the service [history file](#terms-declaration-history).
-2. Update the declaration to stop tracking all terms, by removing every `<terms type>` entries from the  `documents` key in the declaration:
+1. Move the existing terms declaration to the service [history file](#terms-declaration-history).
+2. Update the declaration to stop tracking all terms, by removing every `<terms type>` entries from the  `terms` key in the declaration:
 
 ```json
 {
   "name": "<service name>",
-  "documents": {}
+  "terms": {}
 }
 ```

content/terms/how-to/track-new-terms.md

@@ -82,8 +82,8 @@ Once you have the [service name](#service-name) and the [service ID](#service-id
 ```json
 {
   "name": "<service name>",
-  "documents": {}
+  "terms": {}
 }
 ```
 
-Within the `documents` JSON object, you will now declare terms.
+Within the `terms` JSON object, you will now declare terms.

content/terms/reference/declaration.md

@@ -5,7 +5,7 @@ aliases: "/terms/reference/"
 
 # Terms declaration format reference
 
-Terms are declared in a service declaration file, under the `documents` property.
+Terms are declared in a service declaration file, under the `terms` property.
 
 Most of the time, terms are written in only one source document (for example [Facebook Terms of Service](https://www.facebook.com/legal/terms)) but sometimes terms can be spread across multiple online source documents, and their combination constitutes the terms (for example [Facebook Community Guidelines](https://transparency.fb.com/policies/community-standards/)).
 
@@ -257,7 +257,7 @@ In the case where terms are extracted from one single source document, they are
 
 ```json
   …
-  "documents": {
+  "terms": {
     "<terms type>": {
       "fetch": "…",
       "executeClientScripts": "…",
@@ -275,7 +275,7 @@ When the terms are spread across multiple source documents, they should be decla
 
 ```json
   …
-  "documents": {
+  "terms": {
     "<terms type>": {
         "combine": [
         {
@@ -302,7 +302,7 @@ If some parts of the source documents are repeated, they can be factorised. For
 
 ```json
   …
-  "documents": {
+  "terms": {
     "<terms type>": 
       "executeClientScripts": "…",
       "filter": "…",
@@ -322,7 +322,7 @@ If some parts of the source documents are repeated, they can be factorised. For
 
 ## Terms type
 
-Great, your terms declaration is now almost complete! You simply need to write it under the appropriate terms type in the `documents` JSON object within the service declaration.
+Great, your terms declaration is now almost complete! You simply need to write it under the appropriate terms type in the `terms` JSON object within the service declaration.
 
 In order to distinguish between the many terms that can be associated with a service and enable cross-services comparison of similar terms, we maintain a unique list of terms types in a [dedicated repository](https://github.com/OpenTermsArchive/terms-types).
 

content/terms/tutorials/track.md

@@ -51,7 +51,7 @@ The resulting declaration should look something like this:
     ```json
     {
       "name": "Open Terms Archive",
-      "documents": {
+      "terms": {
         "Privacy Policy": {
           "fetch": "https://opentermsarchive.org/en/privacy-policy",
           "select": ".textcontent"