Merge pull request #1852 from ahstro/fix/gender

Use more inclusive pronouns

admin_manual/configuration_server/occ_command.rst

@@ -466,7 +466,7 @@ This example creates a new calendar for molly::
 
  sudo -u www-data php occ dav:create-calendar molly mollycal
  
-Molly will immediately see these on her Calendar and Contacts pages.
+Molly will immediately see these in the Calendar and Contacts apps.
 
 ``dav:lists-calendars [user]`` will display a table listing the calendars for an given user. 
 This example will list all calendars for user annie::
@@ -1045,7 +1045,7 @@ memberships with the ``user:add`` command. The syntax is::
 
 The ``display-name`` corresponds to the **Full Name** on the Users page in your 
 Nextcloud Web UI, and the ``uid`` is their **Username**, which is their 
-login name. This example adds new user Layla Smith, and adds her to the 
+login name. This example adds new user Layla Smith, and adds them to the 
 **users** and **db-admins** groups. Any groups that do not exist are created:: 
  
  sudo -u www-data php occ user:add --display-name="Layla Smith" 

admin_manual/configuration_user/user_configuration.rst

@@ -81,7 +81,7 @@ information. You may edit this email using the email template editor on your
 Admin page (see :doc:`../configuration_server/email_configuration`).
 
 Set the **Send email to new user**-checkbox allows you to leave the **Password**
-field empty. The user will get an activation-email to set his own password.
+field empty. The user will get an activation-email to set their own password.
 
 Reset a user's password
 -----------------------
@@ -186,13 +186,13 @@ Disable and enable users
 
 .. figure:: ../images/users-actions.png
 
-Sometimes you may want to disable a user without permanently deleting his
+Sometimes you may want to disable a user without permanently deleting their
 settings and files. The user can be activated any time again, without data-loss.
 
 Hover your cursor over their name on the **Users** page until the "..."-menu icon
 appears at the far right. After clicking on it, you will see the **Disable** option.
 
-The user will not longer be able to access his Nextcloud until you enable him again.
+The user will not longer be able to access their Nextcloud until you enable them again.
 Keep in mind that the files, which were shared by this user will not longer be accessible.
 
 You will find all disabled users in the **disabled**-section on the left pane.
@@ -206,7 +206,7 @@ Deleting users
 
 Deleting a user is easy: hover your cursor over their name on the **Users** page
 until the "..."-menu icon appears at the far right. After clicking on it, you will
-see the **Delete** option. Clicking on it, delets a user with all his data immediately.
+see the **Delete** option. Clicking on it, delets a user with all their data immediately.
 
 You'll see an undo button at the top of the page, which remains for some seconds.
 When the undo button is gone you cannot recover the deleted user.

admin_manual/installation/installation_wizard.rst

@@ -63,7 +63,7 @@ satisfied (see :doc:`source_installation` for a detailed listing of required
 and optional PHP modules). You will need the root database login, or any 
 administrator login , and then enter any name you want for your Nextcloud database.
 Be careful your administrator login needs to have the permissions to create
-and modify databases and he needs to have the permissions to grant permissions
+and modify databases and they needs to have the permissions to grant permissions
 to other users.
 
 After you enter your root or administrator login for your database, the 

developer_manual/app/flow.rst

@@ -4,6 +4,6 @@ Nextcloud Flow
 
 Nextcloud Flow is the workflow engine of Nextcloud. It offers flexible, user-defined event-based task automation. Apps can register events or triggers which can start a flow, as well as actions which get executed once a trigger is hit and the constraints are satisfied.
 
-At 36c3 blizzz gave a talk explaining Flow and `how to write actions and triggers. <https://mirror.eu.oneandone.net/projects/media.ccc.de/congress/2019/h264-sd/36c3-oio-174-eng-Building_Nextcloud_Flow_sd.mp4>`_ You can `find the slides of his talk here. <https://nextcloud.com/wp-content/themes/next/assets/files/Building_nextcloud_flow.pdf>`_
+At 36c3 blizzz gave a talk explaining Flow and `how to write actions and triggers. <https://mirror.eu.oneandone.net/projects/media.ccc.de/congress/2019/h264-sd/36c3-oio-174-eng-Building_Nextcloud_Flow_sd.mp4>`_ You can `find the slides of their talk here. <https://nextcloud.com/wp-content/themes/next/assets/files/Building_nextcloud_flow.pdf>`_
 
 Contributions to this documentation are, as always, very welcome!

developer_manual/app/publishing.rst

@@ -68,7 +68,7 @@ Respect the users
 * Apps must respect user privacy. IF user data is sent anywhere, this must be clearly explained and be kept to a minimum for the functioning of an app. Use proper security measures when needed.
 * App authors must provide means to contact them, be it through a bug tracker, forum or mail.
 
-Apps which break the guidelines will lose their 'approved' or 'official' state; and might be blocked from the app store altogether. This also has repercussions for the author, especially in case of security concerns, he/she might find themselves blocked from submitting applications.
+Apps which break the guidelines will lose their 'approved' or 'official' state; and might be blocked from the app store altogether. This also has repercussions for the author, especially in case of security concerns, they might find themselves blocked from submitting applications.
 
 Moving your repo to the Nextcloud organization
 ----------------------------------------------

developer_manual/bugtracker/codereviews.rst

@@ -23,7 +23,7 @@ reviewed!
 How will it work?
 -----------------
 
-#. A developer will submit his changes on GitHub via a pull request (PR).
+#. A developer will submit their changes on GitHub via a pull request (PR).
    `GitHub:help - using pull requests <https://help.GitHub.com/articles/using-pull-requests>`_
 #. Within the pull request the developer could already name other developers (using
    @GitHubusername) and ask them for review.
@@ -32,7 +32,7 @@ How will it work?
    PR author had indicated.
 #. Other developers (either named or at free will) have a look at the changes
    and are welcome to write comments within the comment field.
-#. In case the reviewer is okay with the changes and thinks all his comments and
+#. In case the reviewer is okay with the changes and thinks all their comments and
    suggestions have been taken into account a :+1 on the comment will signal a positive
    review.
 #. Before a pull request will be merged into master or the corresponding

developer_manual/bugtracker/kanban.rst

@@ -77,7 +77,7 @@ Why do we have it?
 
 What does a developer think?
   "Nice! I can safely implement it that way because more than one person has put
-  his brain to the task of coming up with a good solution. Here! Me! I’ll do
+  their brain to the task of coming up with a good solution. Here! Me! I’ll do
   it!"
 
 When can I pull?
@@ -144,7 +144,7 @@ Reviewing
 Why do we have it?
   With the Gherkin Scenario from the Concept Phase reviewers have a checklist to
   test if a Bug has been solved and if an Enhancement works as expected. **The
-  most eager reviewer we have is Drone**. When it comes to testing he soldiers
+  most eager reviewer we have is Drone**. When it comes to testing they soldier
   on going through the different combinations of platform, Web server and
   database.
 

developer_manual/general/security.rst

@@ -216,7 +216,7 @@ Always store user data or configuration files in safe locations, e.g. **nextclou
 Cross site request forgery
 --------------------------
 
-Using `CSRF <http://en.wikipedia.org/wiki/Cross-site_request_forgery>`_ one can trick a user into executing a request that he did not want to make. Thus every POST and GET request needs to be protected against it. The only places where no CSRF checks are needed are in the main template, which is rendering the application, or in externally callable interfaces.
+Using `CSRF <http://en.wikipedia.org/wiki/Cross-site_request_forgery>`_ one can trick a user into executing a request that they did not want to make. Thus every POST and GET request needs to be protected against it. The only places where no CSRF checks are needed are in the main template, which is rendering the application, or in externally callable interfaces.
 
 .. note:: Submitting a form is also a POST/GET request!
 

user_manual/files/deleted_file_management.rst

@@ -28,7 +28,7 @@ scenario illustrates:
 2. User2 (the recipient) deletes a file/folder "sub" inside of "test"
 3. The folder "sub" will be moved to the trashbin of both User1 (owner) and
    User2 (recipient)
-4. But User3 will not have a copy of "sub" in her trash bin
+4. But User3 will not have a copy of "sub" in their trash bin
 
 When User1 deletes "sub" then it is moved to User1's trash bin. It is
 deleted from User2 and User3, but not placed in their trash bins.