Merge branch 'master' into develop

docs/admin/0.17.rst

@@ -58,7 +58,7 @@ with other users, both from the same instance or from the federation.
 
 We think this change will have a really positive impact:
 
-- Admins should be more encline to open their instance to strangers, because copyrighted media
+- Admins should be more inclined to open their instance to strangers, because copyrighted media
   can be upload and shared privately
 - Creators should have a better experience when joining the network, because they can now
   upload their own content and share it over the federation without any admin intervention
@@ -70,12 +70,12 @@ Accessing music
 
 From an end-user perspective, you will be able to browse any artist or album or track
 that is known by your instance, but you'll only be able to listen to content
-that match one of those critaeria:
+that match one of those criteria:
 
 - The content is available is one of your libraries
 - The content is available in a public library
 - The content is available in one library from your instance that has a visibility level set to "instance"
-- The content is available in one of the library you follow
+- The content is available in one of the libraries you follow
 
 Following someone else's library is a four step process:
 
@@ -104,35 +104,35 @@ A better import UI
 ------------------
 
 This version includes a completely new import UI which should make
-file uploading less annoying. Especially it's updating in real-time
+file uploading less annoying. In particular, the UI updates in real-time
 and has a better error reporting.
 
-A Better import engine
+A better import engine
 ----------------------
 
 Funkwhale is known for its quircks during music import. Missing covers,
-splitted albums, bad management of tracks with multiple artists, missing
-data for files imported over federation, bad performance, discrepencies between
-the user provided tags and what is actually stored in the database...
+split albums, bad management of tracks with multiple artists, missing
+data for files imported over federation, bad performance, discrepancies between
+the user-provided tags and what is actually stored in the database...
 
 This should be greatly improved now, as the whole import logic was rewritten
 from scratch.
 
-Import is done completely offline and do not call the MusicBrainz API anymore,
+Import is done completely offline and no longer calls the MusicBrainz API,
 except to retrieve covers if those are not embedded in the imported files.
-MusicBrainzare references are still stored in the database, but we rely solely
+MusicBrainz references are still stored in the database, but we rely solely
 on the tags from the audio file now.
 
 This has two positive consequences:
 
-- Improved performance for both small and big imports (possibly by a factor 10)
+- Improved performance for both small and big imports (possibly by a factor of 10)
 - More reliable import result: if your file is tagged in a specific way, we will only
   use tags for the import.
 
 Imports from federation, command-line and UI/API all use the same code,
 which should greatly reduce the bugs/discrepencies.
 
-Finally, the import engine now understand the difference between a track artist
+Finally, the import engine now understands the difference between a track artist
 and an album artist, which should put an end to the album splitting issues
 for tracks that had a different artist than the album artist.
 
@@ -140,10 +140,10 @@ What will break
 ---------------
 
 If you've read until here, you can probably understand that all of these changes
-comes at a cost: version 0.17 contains breaking changes, feature were removed
-or changed.
+comes at a cost: version 0.17 contains breaking changes, removed features and other
+changes.
 
-Those features were removed:
+The following features were removed:
 
 - YouTube imports: for copyright reasons, keeping this in the core was not possible
 - Music requests: those are now less useful since anyone can upload content
@@ -171,13 +171,13 @@ bind content imported by each one to this library.
 
 Libraries created this way will have a different visibility level depending of your instance configuration:
 
-- If your instance requires authentication to access the API / Listen to music, libraries will
+- If your instance requires authentication to access the API / listen to music, libraries will
   be marked with "instance"  visibility. As a result, all users from the instance will still
   be able to listen to all the music of the instance after the migration
-- If your instance does not requires authentication to access the API / Listen to music,
+- If your instance does not require authentication to access the API / listen to music,
   libraries will be completely public, allowing anyone to access the content (including federation)
 
-This script will contain other database-related operations, but the impact will remain
+This script will also contain other database-related operations, but the impact will remain
 invisible.
 
 
@@ -199,7 +199,7 @@ On non docker-setups::
     sudo -u funkwhale -H -E /srv/funkwhale/virtualenv/bin/python api/manage.py script create_actors --no-input
     sudo -u funkwhale -H -E /srv/funkwhale/virtualenv/bin/python api/manage.py script migrate_to_user_libraries --no-input
 
-If the scripts ends without errors, you're instance should be updated and ready to use :)
+If the scripts complete without errors, your instance should be updated and ready to use :)
 
 .. note::
 

docs/installation/index.rst

@@ -47,7 +47,7 @@ Funkwhale packages are available for the following platforms:
 - `YunoHost 3 <https://yunohost.org/>`_: https://github.com/YunoHost-Apps/funkwhale_ynh (kindly maintained by `@Jibec <https://github.com/Jibec>`_)
 - ArchLinux (as an AUR package): if you'd rather use a package, check out this alternative installation method on ArchLinux: https://wiki.archlinux.org/index.php/Funkwhale (package and wiki kindly maintained by getzee)
 - `NixOS <https://github.com/mmai/funkwhale-nixos>`_ (kindly maintained by @mmai)
-- `Helm chart <https://gitlab.com/ananace/charts/>`_ to install Funkwhale on Kubenertes (kindly maintained by @ananace)
+- `Helm chart <https://gitlab.com/ananace/charts/>`_ to install Funkwhale on Kubernetes (kindly maintained by `@ananace <https://gitlab.com/ananace>`_)
 
 Project architecture
 --------------------
@@ -109,23 +109,23 @@ Running Funkwhale on the develop branch
 ---------------------------------------
 
 Traditional deployments are done using tagged releases. However, you
-may want to benefits from the latest change available, or the help detect
+may want to benefit from the latest changes available, or to help detect
 bugs before they are included in actual releases.
 
 To do that, you'll need to run your instance on the develop branch,
 which contains all the unreleased changes and features of the next version.
 
 Please take into account that the develop branch
-may be unstable and will contain bugs that may affect the well being of your
+may be unstable and will contain bugs that may affect the well-being of your
 instance. If you are comfortable with that, you need to backup at least your database
-before pulling latest changes from the develop branch.
+before pulling the latest changes from the develop branch.
 
 Otherwise, the deployment process is similar to deploying with releases.
 You simply need to use ``export FUNKWHALE_VERSION=develop``
 in the installation and upgrade process instead of a real version number,
 as we build artifacts on the development branch the same way we do for releases.
 
-It's also recommended to check out the `develop release notes <https://dev.funkwhale.audio/funkwhale/funkwhale/blob/develop/changes/notes.rst>_` before upgrading,
+It's also recommended to check out the `develop release notes <https://dev.funkwhale.audio/funkwhale/funkwhale/blob/develop/changes/notes.rst>`_ before upgrading,
 since you may have to apply manual actions for your instance to continue to work. Such actions are labelled with ``[manual action required]`` in the releases notes.
 
 .. _frontend-setup:
@@ -216,7 +216,7 @@ On non-docker deployments, run the following commands:
 
 .. note::
 
-    The resulting file should not contain any variable such as ``${FUNKWHALE_HOSTNAME}``.
+    The resulting file should not contain any variables such as ``${FUNKWHALE_HOSTNAME}``.
     You can check that using this command::
 
         grep '${' /etc/nginx/sites-available/funkwhale.conf
@@ -285,7 +285,7 @@ Add the following to your ``.env`` file::
 
     REVERSE_PROXY_TYPE=apache2
 
-Then restart Funkwhale. This is needed to ensure Funkwhale provide proper headers for media file serving.
+Then restart Funkwhale. This is needed to ensure Funkwhale provides proper headers for media file serving.
 
 Then, download our sample virtualhost file:
 
@@ -295,7 +295,7 @@ Then, download our sample virtualhost file:
     ln -s /etc/apache2/sites-available/funkwhale.conf /etc/apache2/sites-enabled/
 
 You can tweak the configuration file according to your setup, especially the
-TLS configuration. Otherwise, defaults, should work if you followed the
+TLS configuration. Otherwise, defaults should work if you followed the
 installation guide.
 
 .. note::
@@ -340,5 +340,5 @@ to the file to serve to the user, and will be picked by nginx, but never sent
 back to the client.
 
 Using this technique, we can ensure music files are covered by the authentication
-and permission policy of your instance, while keeping as much as performance
+and permission policy of your instance, while remaining as performant
 as possible.

docs/users/apps.rst

@@ -187,7 +187,7 @@ Mobydick (Desktop)
 ^^^^^^^^^^^^^^^^^^
 
 - Price: free
-- Website: https://github.com/BaptisteGelez/mobydick
+- Website: https://github.com/AnaGelez/mobydick
 
 Mobydick is a free and open-source desktop application for linux (based on GTK+) to easily download
 tracks, albums and discography from a Funkwhale instance.