Merge pull request #3931 from luixxiul/fix

Replace double or triple dots with horizontal ellipses (“…” U+2026)

CHANGELOG.md

@@ -547,7 +547,7 @@ Talk about a jack of all trades! The [UNIX philosophy](https://en.wikipedia.org/
 
 On a related note, we also had a large chain of reverse-proxies in the mix. In the worst case, it was something like this: (Traefik -> `matrix-nginx-proxy:8080` -> `matrix-nginx-proxy:12080` -> `matrix-synapse-reverse-proxy-companion:8008` -> `matrix-synapse:8008`).
 
-Due to complexity and the playbook's flexibility (trying to accommodate a mix of tens of components), many layers of indirection were necessary. We do like reverse-proxies, but.. not quite enough to enjoy going through a chain of ~4 of them before reaching the target service.
+Due to complexity and the playbook's flexibility (trying to accommodate a mix of tens of components), many layers of indirection were necessary. We do like reverse-proxies, but… not quite enough to enjoy going through a chain of ~4 of them before reaching the target service.
 
 After **a ton of work** in the last weeks (200+ commits, which changed 467 files - 8684 insertions and 8913 deletions), **we're finally saying goodbye** to `matrix-nginx-proxy`.
 
@@ -1146,7 +1146,7 @@ Others still, wanted to run Matrix locally (no SSL certificates), regardless of
 
 Despite this operational complexity, things worked and were reasonably flexible to adapt to all these situations.
 
-When using `matrix-nginx-proxy` as is, we still had another problem - one of **internal playbook complexity**. Too many services need to be web-exposed (port 80/443, SSL certificates). Because of this, they all had to integrate with the `matrix-nginx-proxy` role. Tens of different roles explicitly integrating with `matrix-nginx-proxy` is not what we call clean. The `matrix-nginx-proxy` role contains variables for many of these roles (yikes). Other roles were more decoupled from it and were injecting configuration into `matrix-nginx-proxy` at runtime - see all the `inject_into_nginx_proxy.yml` task files in this playbook (more decoupled, but still.. yikes).
+When using `matrix-nginx-proxy` as is, we still had another problem - one of **internal playbook complexity**. Too many services need to be web-exposed (port 80/443, SSL certificates). Because of this, they all had to integrate with the `matrix-nginx-proxy` role. Tens of different roles explicitly integrating with `matrix-nginx-proxy` is not what we call clean. The `matrix-nginx-proxy` role contains variables for many of these roles (yikes). Other roles were more decoupled from it and were injecting configuration into `matrix-nginx-proxy` at runtime - see all the `inject_into_nginx_proxy.yml` task files in this playbook (more decoupled, but still… yikes).
 
 The next problem is one of **efficiency, interoperability and cost-saving**. We're working on other playbooks:
 
@@ -1415,7 +1415,7 @@ The Docker SDK for Python (named `docker-python`, `python-docker`, etc. on the d
 
 If you're hitting issues with Docker installation or Docker SDK for Python installation, consider reporting bugs or contributing to these other projects.
 
-These additional roles are downloaded into the playbook directory (to `roles/galaxy`) via an `ansible-galaxy ..` command. `make roles` is an easy shortcut for invoking the `ansible-galaxy` command to download these roles.
+These additional roles are downloaded into the playbook directory (to `roles/galaxy`) via an `ansible-galaxy …` command. `make roles` is an easy shortcut for invoking the `ansible-galaxy` command to download these roles.
 
 
 # 2022-11-20
@@ -1428,7 +1428,7 @@ These additional roles are downloaded into the playbook directory (to `roles/gal
 
 Previously, `matrix-nginx-proxy` forwarded requests to Synapse directly. When Synapse is running in worker mode, the reverse-proxying configuration is more complicated (different requests need to go to different Synapse worker processes). `matrix-nginx-proxy` had configuration for sending each URL endpoint to the correct Synapse worker responsible for handling it. However, sometimes people like to disable `matrix-nginx-proxy` (for whatever reason) as detailed in [Using your own webserver, instead of this playbook's nginx proxy](docs/configuring-playbook-own-webserver.md).
 
-Because `matrix-nginx-proxy` was so central to request forwarding, when it was disabled and Synapse was running with workers enabled, there was nothing which could forward requests to the correct place anymore.. which caused [problems such as this one affecting Dimension](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2090).
+Because `matrix-nginx-proxy` was so central to request forwarding, when it was disabled and Synapse was running with workers enabled, there was nothing which could forward requests to the correct place anymore… which caused [problems such as this one affecting Dimension](https://github.com/spantaleev/matrix-docker-ansible-deploy/issues/2090).
 
 ### Solution
 
@@ -2199,7 +2199,7 @@ To migrate to the new setup, expect a few minutes of downtime, while you follow
     matrix_postgres_connection_password: 'YOUR_POSTGRES_PASSWORD_HERE'
     ```
 
-.. where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
+… where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
 
 4. Stop all services: `ansible-playbook -i inventory/hosts setup.yml --tags=stop`
 5. Log in to the server via SSH. The next commands will be performed there.
@@ -2211,7 +2211,7 @@ To migrate to the new setup, expect a few minutes of downtime, while you follow
     CREATE ROLE matrix LOGIN SUPERUSER PASSWORD 'YOUR_POSTGRES_PASSWORD_HERE';
     ```
 
-.. where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
+… where `YOUR_POSTGRES_PASSWORD_HERE` is to be replaced with the password you generated during step #2.
 
 9. Execute the following queries as you see them (no modifications necessary, so you can just **paste them all at once**):
 
@@ -3630,7 +3630,7 @@ Changing that value allows you to potentially decrease RAM usage or to increase
 
 `--log-driver=none` is used for all Docker containers now.
 
-All these containers are started through systemd anyway and get logged in journald, so there's no need for Docker to be logging the same thing using the default `json-file` driver. Doing that was growing `/var/lib/docker/containers/..` infinitely until service/container restart.
+All these containers are started through systemd anyway and get logged in journald, so there's no need for Docker to be logging the same thing using the default `json-file` driver. Doing that was growing `/var/lib/docker/containers/…` infinitely until service/container restart.
 
 As a result of this, things like `docker logs matrix-synapse` won't work anymore. `journalctl -u matrix-synapse` is how one can see the logs.
 

docs/ansible.md

@@ -42,7 +42,7 @@ To run Ansible in a (Docker) container on the Matrix server itself, you need to
 - you **either** need to install Docker manually first. Follow [the upstream instructions](https://docs.docker.com/engine/install/) for your distribution and consider setting `matrix_playbook_docker_installation_enabled: false` in your `vars.yml` file, to prevent the playbook from installing Docker
 - **or** you need to run the playbook in another way (e.g. [Running Ansible in a container on another computer (not the Matrix server)](#running-ansible-in-a-container-on-another-computer-not-the-matrix-server)) at least the first time around
 
-Once you have a working Docker installation on the server, **clone the playbook** somewhere on the server and configure it as per usual (`inventory/hosts`, `inventory/host_vars/..`, etc.), as described in [configuring the playbook](configuring-playbook.md).
+Once you have a working Docker installation on the server, **clone the playbook** somewhere on the server and configure it as per usual (`inventory/hosts`, `inventory/host_vars/…`, etc.), as described in [configuring the playbook](configuring-playbook.md).
 
 You would then need to add `ansible_connection=community.docker.nsenter` to the host line in `inventory/hosts`. This tells Ansible to connect to the "remote" machine by switching Linux namespaces with [nsenter](https://man7.org/linux/man-pages/man1/nsenter.1.html), instead of using SSH.
 

docs/configuring-playbook-bot-baibot.md

@@ -87,7 +87,7 @@ If `matrix_admin` is already configured in your `vars.yml` configuration, you ca
 #   - "@*:example.com"
 #   - "@admin:example.net"
 #
-# .. unless you've made yourself an admin of all bots/bridges like this:
+# … unless you've made yourself an admin of all bots/bridges like this:
 #
 # matrix_admin: '@yourAdminAccount:{{ matrix_domain }}'
 ```

docs/configuring-playbook-bridge-postmoogle.md

@@ -37,7 +37,7 @@ matrix_postmoogle_password: PASSWORD_FOR_THE_BOT
 # matrix_postmoogle_admins:
 #  - '@yourAdminAccount:{{ matrix_domain }}'
 #
-# .. unless you've made yourself an admin of all bots/bridges like this:
+# … unless you've made yourself an admin of all bots/bridges like this:
 #
 # matrix_admin: '@yourAdminAccount:{{ matrix_domain }}'
 ```

docs/configuring-playbook-matrix-corporal.md

@@ -48,7 +48,7 @@ matrix_corporal_policy_provider_config: |
     "TimeoutMilliseconds": 300
   }
 
-# If you also want to enable Matrix Corporal's HTTP API..
+# If you also want to enable Matrix Corporal's HTTP API…
 matrix_corporal_http_api_enabled: true
 matrix_corporal_http_api_auth_token: "AUTH_TOKEN_HERE"
 

docs/configuring-playbook-ssl-certificates.md

@@ -50,7 +50,7 @@ traefik_ssl_dir_enabled: true
 
 # Tell Traefik to load our custom ssl key pair by extending provider configuration.
 # The key pair files are created below, in `aux_file_definitions`.
-# The `/ssl/..` path is an in-container path, not a path on the host (like `/matrix/traefik/ssl`). Do not change it!
+# The `/ssl/…` path is an in-container path, not a path on the host (like `/matrix/traefik/ssl`). Do not change it!
 traefik_provider_configuration_extension_yaml:
   tls:
     certificates:

docs/configuring-playbook-sygnal.md

@@ -23,11 +23,11 @@ matrix_sygnal_apps:
   com.example.myapp.ios:
     type: apns
     keyfile: /data/my_key.p8
-    # .. more configuration ..
+    # … more configuration …
   com.example.myapp.android:
     type: gcm
     api_key: your_api_key_for_gcm
-    # .. more configuration ..
+    # … more configuration …
 
 aux_file_definitions:
   - dest: "{{ matrix_sygnal_data_path }}/my_key.p8"
@@ -48,7 +48,7 @@ To configure [APNS](https://developer.apple.com/notifications/) (Apple Push Noti
 
 - makes use of the [`aux` role](https://github.com/mother-of-all-self-hosting/ansible-role-aux) (and its `aux_file_definitions` variable) to make the playbook install files into `/matrix/sygnal/data` (the `matrix_sygnal_data_path` variable). See [`defaults/main.yml` file](https://github.com/mother-of-all-self-hosting/ansible-role-aux/blob/main/defaults/main.yml) of the `aux` role for usage examples. It also makes sure the files are owned by `matrix:matrix`, so that Sygnal can read them. Of course, you can also install these files manually yourself, if you'd rather not use `aux`.
 
-- references these files in the Sygnal configuration (`matrix_sygnal_apps`) using a path like `/data/..` (the `/matrix/sygnal/data` directory on the host system is mounted into the `/data` directory inside the container)
+- references these files in the Sygnal configuration (`matrix_sygnal_apps`) using a path like `/data/…` (the `/matrix/sygnal/data` directory on the host system is mounted into the `/data` directory inside the container)
 
 ### Adjusting the Sygnal URL
 

docs/configuring-playbook-synapse-s3-storage-provider.md

@@ -47,7 +47,7 @@ matrix_synapse_ext_synapse_s3_storage_provider_config_storage_class: STANDARD #
 # For additional advanced settings, take a look at `roles/custom/matrix-synapse/defaults/main.yml`
 ```
 
-If you have existing files in Synapse's media repository (`/matrix/synapse/storage/media-store/..`):
+If you have existing files in Synapse's media repository (`/matrix/synapse/storage/media-store/…`):
 
 - new files will start being stored both locally and on the S3 store
 - the existing files will remain on the local filesystem only until [migrating them to the S3 store](#migrating-your-existing-media-files-to-the-s3-store)
@@ -85,7 +85,7 @@ Instead of running the above commands manually in the shell, you can also run th
 - it's what the upstream project demonstrates and it teaches you how to use the `s3_media_upload` tool
 - allows you to check and verify the output of each command, to catch mistakes
 - includes progress bars and detailed output for each command
-- allows you to easily interrupt slow-running commands, etc. (the `/matrix/synapse/ext/s3-storage-provider/bin/migrate` starts a container without interactive TTY support, so `Ctrl+C` may not work and you and require killing via `docker kill ..`)
+- allows you to easily interrupt slow-running commands, etc. (the `/matrix/synapse/ext/s3-storage-provider/bin/migrate` starts a container without interactive TTY support, so `Ctrl+C` may not work and you and require killing via `docker kill …`)
 
 ### Using another tool in combination with `s3_media_upload`
 
@@ -140,7 +140,7 @@ As described in [How it works?](#how-it-works) above, when new media is uploaded
 By default, we periodically ensure that all local files are uploaded to S3 and are then removed from the local filesystem. This is done automatically using:
 
 - the `/matrix/synapse/ext/s3-storage-provider/bin/migrate` script
-- .. invoked via the `matrix-synapse-s3-storage-provider-migrate.service` service
-- .. triggered by the `matrix-synapse-s3-storage-provider-migrate.timer` timer, every day at 05:00
+- … invoked via the `matrix-synapse-s3-storage-provider-migrate.service` service
+- … triggered by the `matrix-synapse-s3-storage-provider-migrate.timer` timer, every day at 05:00
 
-So.. you don't need to perform any maintenance yourself.
+So… you don't need to perform any maintenance yourself.

docs/configuring-playbook-synapse.md

@@ -130,7 +130,7 @@ matrix_synapse_container_image_customizations_templates_git_repository_keyscan_h
 # If your git repository is public, do not define the private key (remove the variable).
 matrix_synapse_container_image_customizations_templates_git_repository_ssh_private_key: |
   -----BEGIN OPENSSH PRIVATE KEY-----
-  ....
+  …
   -----END OPENSSH PRIVATE KEY-----
 ```
 

docs/faq.md

@@ -98,7 +98,7 @@ Reading the documentation of this Ansible playbook, you may also be thinking:
 
 > I don't know what [Ansible](https://www.ansible.com/) is. I don't know what [Docker](https://www.docker.com/) is. This looks more complicated.
 
-.. so you may be leaning toward [installing Synapse manually](https://github.com/element-hq/synapse/blob/master/INSTALL.md).
+… so you may be leaning toward [installing Synapse manually](https://github.com/element-hq/synapse/blob/master/INSTALL.md).
 
 The problem with a manual installation is:
 

docs/installing.md

@@ -65,7 +65,7 @@ You can now:
 
 - [Importing `media_store` data files from an existing Synapse installation](importing-synapse-media-store.md) (optional)
 
-.. and then proceed to starting all services:
+… and then proceed to starting all services:
 
 ```sh
 ansible-playbook -i inventory/hosts setup.yml --tags=ensure-matrix-users-created,start

group_vars/matrix_servers

@@ -268,7 +268,7 @@ matrix_homeserver_sliding_sync_url: "{{ matrix_sliding_sync_base_url if matrix_s
 # - Matrix utility services (bridges, bots) get a level of 2000/2200, so that:
 #   - they can start before the reverse-proxy
 #   - so that, when the reverse-proxy is up (Matrix is up), all bots and bridges can be interacted with
-# - monitoring services (Prometheus, Grafana, ..) get a level of 4000 - they can start later than all-of-Matrix
+# - monitoring services (Prometheus, Grafana, …) get a level of 4000 - they can start later than all-of-Matrix
 # - services which aren't time-sensitive (various crons and timers) get a level of 5000 - they can start later than all-of-Matrix
 devture_systemd_service_manager_services_list_auto: |
   {{

i18n/justfile

@@ -9,7 +9,7 @@ default:
 
 # Extracts original English strings (translation templates) into the `translation-templates/` directory
 extract-translation-templates: _venv
-    @echo "Extracting translation templates..."
+    @echo "Extracting translation templates…"
     PATH={{ justfile_directory() }}/.venv/bin:$PATH {{ justfile_directory() }}/bin/extract-translation-templates.sh
 
 # Syncs the translation templates (affects `translation-templates/`) and strings (affects `locales/*`) for all published languages (`PUBLISHED_LANGUAGES`)
@@ -24,7 +24,7 @@ sync-for-all-known-languages:
     #!/bin/sh
     find {{ justfile_directory() }}/locales -mindepth 1 -maxdepth 1 -type d | while read path ; do
         language=$(basename "$path")
-        echo "Syncing for language $language.."
+        echo "Syncing for language $language…"
         {{ just_executable() }} sync-for-language $language
     done
 
@@ -51,7 +51,7 @@ build-for-all-known-languages:
     #!/bin/sh
     find {{ justfile_directory() }}/locales -mindepth 1 -maxdepth 1 -type d | while read path ; do
         language=$(basename "$path")
-        echo "Building for language $language.."
+        echo "Building for language $language…"
         {{ just_executable() }} build-for-language $language
     done
 
@@ -59,7 +59,7 @@ build-for-all-known-languages:
 _venv:
     #!/bin/sh
     if [ ! -f {{ justfile_directory() }}/.venv/bin/sphinx-build ]; then
-        echo "No sphinx-build found, creating virtual environment and installing requirements..."
+        echo "No sphinx-build found, creating virtual environment and installing requirements…"
         uv venv {{ justfile_directory() }}/.venv
         VIRTUAL_ENV={{ justfile_directory() }}/.venv uv pip install -r {{ justfile_directory() }}/requirements.txt
     fi