misc: various small typo fixes and improvements

Thanks to suggestions from Óvári.

Change-Id: I6687a4ce453189660008b5815e35dd52295cf727

build/dependencies.rst

@@ -19,7 +19,7 @@ Building the Jami daemon currently requires the following tools and
 libraries:
 
 - GNU Autotools (autoconf, autoconf-archive, autopoint, and automake)
-- GNU Compiler Collection's C++ compiler (GCC's g++)
+- GCC (GNU Compiler Collection) C++ compiler (g++)
 - GNU Make
 - GNU gettext
 - GNU Libtool
@@ -101,7 +101,7 @@ repository.
 jami-client-qt
 --------------
 
-Building the Jami Qt client currently requires the following tools and
+Building the Jami client currently requires the following tools and
 libraries:
 
 - jami-daemon

build/introduction.rst

@@ -43,6 +43,6 @@ daemon/library:
    will be running as a separate process by itself.  This is greatly
    flexible for communicating with and controlling the daemon through
    other means (for example small utility scripts) simultaneously
-   while the Jami Qt client also uses and interacts with it.
+   while the Qt-based Jami client also uses and interacts with it.
    The associated cost of this added flexibility is the overhead of
    using DBus.

developer/swarm.md

@@ -469,7 +469,7 @@ Alice wants to invite Bob:
     b. Else, Alice sends on the SIP channel
 4. Two possibilities for Bob
     a. Receives the invite, a signal is emitted for the client
-    b. Not connected, so will never receive the request cause Alice must not know if Bob just ignored or blocked Alice. The only way is to regenerate a new invite via a new message (cf next scenario)
+    b. Not connected, so will never receive the request cause Alice must not know if Bob just ignored or blocked Alice. The only way is to regenerate a new invite via a new message (cf. next scenario)
 
 #### Process to send a message to someone
 

developer/synchronization-protocol.md

@@ -9,9 +9,9 @@ A lot of scenarios are defined in the {doc}`Swarm design document <swarm>`, howe
 
 Device sync were done via the DHT. Because every value MUST NOT exceed 64k, conversations were not sent in device sync, nor member profiles, because it's too heavy. This is a problem and MUST be improved.
 
-In the old method, the daemon is listening on "inbox:DEVICE_ID" for DeviceSync values which contains the contact list to sync (cf `AccountManager::startSync()`);
+In the old method, the daemon is listening on "inbox:DEVICE_ID" for DeviceSync values which contains the contact list to sync (cf. `AccountManager::startSync()`);
 
-**NOTE:** The curretn **DeviceSync** value present on the **DHT** is deprecated with this draft.
+**NOTE:** The current **DeviceSync** value present on the **DHT** is deprecated with this draft.
 
 ## New method
 
@@ -21,7 +21,7 @@ Now, this is the scenario used to sync:
 
 1. When the device (*A*) goes online, it announces its presence via a DeviceAnnouncement like the OldMethod
 2. Other devices (*!A*) will detect that announce and will ask this device through the **ConnectionManager** to open a new channel named "sync://DEVICE_ID_A". (Note: A will get announcement from other devices, so it will asks for sync channels too).
-3. As soon as this channel is opened, the device which is asking this channel will send a **DeviceSync** (cf next part) value containing its known conversations and contacts.
+3. As soon as this channel is opened, the device which is asking this channel will send a **DeviceSync** (cf. next part) value containing its known conversations and contacts.
 4. *A* will check the **DeviceSync** value and:
     + Remove contacts if it detects removed contacts
     + Add contacts if it detects added contacts

developer/synchronizing-profiles.md

@@ -22,7 +22,7 @@ At the beginning of a call, generally client sends the vCard. However, this meth
 
 ### Send to contact's devices
 
-When connecting to a new devices, a SIP or a sync channel is done. When this channel is ready, we check if we need to send the profile. To do this, the hash of the profile is compared to the one in the cache (`${cacheDir}/${accId}/vcard/sha3` like `~/.cache/jami/xxxxx/vcard/sha3`on GNU/Linux), and the file `${cacheDir}/${accId}/vcard/deviceId` is checked). cf `JamiAccount::needToSendProfile()`. If not present, the profile of the account is sent. Typically, the name of the channel will be "vcard://xxx" where the issuer is the one sending the profile.
+When connecting to a new devices, a SIP or a sync channel is done. When this channel is ready, we check if we need to send the profile. To do this, the hash of the profile is compared to the one in the cache (`${cacheDir}/${accId}/vcard/sha3` like `~/.cache/jami/xxxxx/vcard/sha3`on GNU/Linux), and the file `${cacheDir}/${accId}/vcard/deviceId` is checked). cf. `JamiAccount::needToSendProfile()`. If not present, the profile of the account is sent. Typically, the name of the channel will be "vcard://xxx" where the issuer is the one sending the profile.
 
 ### Multidevices
 

user/all-features-by-client.md

@@ -52,7 +52,7 @@ Legend:
 
 
 \* This enables 4k video calling support  
-\*\* cf {ref}`user/faq:How can I configure the audio processor?` in
+\*\* cf. {ref}`user/faq:How can I configure the audio processor?` in
 the FAQ
 
 (1) only on X (not Wayland)  

user/bug-report-guide.md

@@ -162,7 +162,7 @@ save time by providing this information below the Expected results.
 
 ### Logs
 
-#### Qt client (GNU/Linux, Windows, macOS)
+#### Qt-based Jami client (GNU/Linux, Windows, macOS)
 
 Go to the General settings.  In the Troubleshoot section, you can
 click on "Open logs", where you will be able to get statistics ("Show