Fuxed minor issues with the rest of the pages

docs/user/actions.md

@@ -166,7 +166,7 @@ the [download-artifact](https://code.forgejo.org/actions/download-artifact) acti
 
 When a `job` starts, it can communicate with the `Forgejo runner` to
 fetch commonly used files that were saved by previous runs. For
-instance the https://code.forgejo.org/actions/setup-go action will do
+instance, the https://code.forgejo.org/actions/setup-go action will do
 that by default to save downloading and compiling packages found in
 `go.mod`.
 

docs/user/agit-support.md

@@ -12,9 +12,9 @@ Using Push Options (`-o`) and a [Refspec](https://git-scm.com/book/en/v2/Git-Int
 
 ## Creating Pull Requests
 
-For clarity reasons, this document will lead with some examples first.
+For clarity, this document will start with some examples.
 
-A full list of the parameters, as well as information on avoiding duplicate Pull Requests when rebasing or amending a commit, will follow.
+A full list of the parameters, as well as information on avoiding duplicate Pull Requests when rebasing or amending commits, will follow.
 
 ### Usage Examples
 
@@ -24,7 +24,7 @@ Suppose that you cloned a repository and created a new commit on top of the `mai
 git push origin HEAD:refs/for/main -o topic="agit-typo-fixes"
 ```
 
-The topic will be visible in the Pull Request and it will be used to associate further commits to the same Pull Request. Under the hood, it is essentially just a branch.
+The topic will be visible in the Pull Request and it will be used to associate further commits with the same Pull Request. Under the hood, it is essentially just a branch.
 
 It can also be supplied directly using the `<session>` parameter in the **Refspec**, which will set the topic as `topic-branch` and push the **currently checked out branch**:
 
@@ -61,7 +61,7 @@ git config branch.local-branch.merge refs/for/main/topic-branch
 ```
 
 After doing so, you can now simply run `git push` to push commits to your pull request, without having to specify the refspec.
-This also will allow you to pull, fetch, rebase, etc. from the AGit pull request by default.
+This will also allow you to pull, fetch, rebase, etc., from the AGit pull request by default.
 
 #### Pushing a non-checked-out reference (non-HEAD)
 
@@ -78,16 +78,16 @@ git push origin local-branch:refs/for/remote-branch/topic
 
 The following parameters are available:
 
-- `HEAD`: The target branch **(required)**
+- `HEAD`: The local reference being pushed (e.g., `HEAD`, `my-branch`, a commit hash) **(required)**
 - `refs/<for|draft|for-review>/<branch>/<session>`: Refspec **(required)**
   - `for`/`draft`/`for-review`: This parameter describes the Pull Request type. **for** opens a normal Pull Request. **draft** and **for-review** are currently silently ignored.
   - `<branch>`: The target branch that a Pull Request should be merged against **(required)**
-  - `<session>`: The local branch that should be submitted remotely. **If left empty,** the currently checked out branch will be submitted by default, however, you **must** use `topic`.
+  - `<session>`: The session identifier or topic for the remote pull request. **If left empty,** the topic must be supplied using the `-o topic` option.
 - `-o <topic|title|description|force-push>`: Push options
-  - `topic`: Essentially an identifier. **If left empty,** the value of `<session>`, if present, will also be used for the topic. Otherwise, Forgejo will return an error. If you want to push additional commits to a Pull Request that was created using AGit, you **must** use the same topic.
+  - `topic`: Essentially an identifier. **If left empty,** the value of `<session>`, if present, will be used for the topic. Otherwise, Forgejo will return an error. If you want to push additional commits to a Pull Request that was created using AGit, you **must** use the same topic.
   - `title`: Title of the Pull Request. **If left empty,** the first line of the first new Git commit will be used instead.
   - `description`: Description of the Pull Request.
-  - `force-push`: Necessary when rebasing, amending or [retroactively modifying](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) your previous commits. Otherwise, a new Pull Request will be opened, **even if you use the same topic**. If used, the value of this parameter should be set to `true`.
+  - `force-push`: Necessary when rebasing, amending, or [retroactively modifying](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History) your previous commits. Otherwise, a new Pull Request will be opened, **even if you use the same topic**. If used, the value of this parameter should be set to `true`.
 
 Forgejo relies on the `topic` parameter and a linear commit history in order to associate new commits with an existing Pull Request.
 

docs/user/api-usage.md

@@ -65,7 +65,7 @@ interface: `Settings | Applications | Generate New Token`.
 
 Access tokens obtained from Forgejo's OAuth2 provider are accepted by these methods:
 
-- `Authorization bearer ...` header in HTTP headers
+- `Authorization: Bearer ...` header in HTTP headers
 - `token=...` parameter in URL query string
 - `access_token=...` parameter in URL query string
 
@@ -74,7 +74,7 @@ Access tokens obtained from Forgejo's OAuth2 provider are accepted by these meth
 For historical reasons, Forgejo needs the word `token` included before
 the API key token in an authorization header, like this:
 
-```sh
+```
 Authorization: token 65eaa9c8ef52460d22a93307fe0aee76289dc675
 ```
 
@@ -92,7 +92,7 @@ the `token=` string in a GET request.
 
 ## Pagination
 
-The API supports pagination. The `page` and `limit` parameters are used to specify the page number and the number of items per page. As well, the `Link` header is returned with the next, previous, and last page links if there are more than one pages. The `x-total-count` is also returned to indicate the total number of items.
+The API supports pagination. The `page` and `limit` parameters are used to specify the page number and the number of items per page. As well, the `Link` header is returned with the next, previous, and last page links if there are more than one page. The `x-total-count` is also returned to indicate the total number of items.
 
 ```sh
 curl -v "http://localhost/api/v1/repos/search?limit=1"
@@ -116,7 +116,7 @@ $ curl https://codeberg.org/api/v1/settings/api
 
 ## API Guide:
 
-API Reference guide is auto-generated by swagger and available on:
+API Reference guide is auto-generated by Swagger and available on:
 `https://forgejo.your.host/api/swagger`.
 
 The OpenAPI document is at:

docs/user/authentication.md

@@ -37,11 +37,11 @@ Both the LDAP via BindDN and the simple auth LDAP share the following fields:
 - Username attribute (optional)
 
   - The attribute of the user's LDAP record containing the user name. Given
-    attribute value will be used for new Forgejo account user name after first
-    successful sign-in. Leave empty to use login name given on sign-in form.
-  - This is useful when supplied login name is matched against multiple
-    attributes, but only single specific attribute should be used for Forgejo
-    account name, see "User Filter".
+    attribute value will be used for the new Forgejo account username after the first
+    successful sign-in. Leave empty to use the login name given on the sign-in form.
+  - This is useful when the supplied login name is matched against multiple
+    attributes, but only a single specific attribute should be used for the Forgejo
+    account name; see "User Filter".
   - Example: `uid`
   - Example for Microsoft Active Directory (AD): `sAMAccountName`
 
@@ -85,24 +85,24 @@ Adds the following fields:
 
 - User Filter **(required)**
   - An LDAP filter declaring how to find the user record that is attempting to
-    authenticate. The `%[1]s` matching parameter will be substituted with login
-    name given on sign-in form.
+    authenticate. The `%[1]s` matching parameter will be substituted with the login
+    name given on the sign-in form.
   - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
   - Example for Microsoft Active Directory (AD): `(&(objectCategory=Person)(memberOf=CN=user-group,OU=example,DC=example,DC=org)(sAMAccountName=%s)(!(UserAccountControl:1.2.840.113556.1.4.803:=2)))`
-  - To substitute more than once, `%[1]s` should be used instead, e.g. when
-    matching supplied login name against multiple attributes such as user
-    identifier, email or even phone number.
+  - To substitute more than once, `%[1]s` should be used instead, e.g., when
+    matching the supplied login name against multiple attributes such as a user
+    identifier, email, or even phone number.
   - Example: `(&(objectClass=Person)(|(uid=%[1]s)(mail=%[1]s)(mobile=%[1]s)))`
 - Enable user synchronization
   - This option enables a periodic task that synchronizes the Forgejo users with
-    the LDAP server. The default period is every 24 hours but that can be
-    changed in the app.ini file. See the _cron.sync_external_users_ section in
+    the LDAP server. The default period is every 24 hours, but that can be
+    changed in the app.ini file. See the `[cron.sync_external_users]` section in
     the [sample
     app.ini](https://codeberg.org/forgejo/forgejo/src/branch/forgejo/custom/conf/app.example.ini)
     for detailed comments about that section. The _User Search Base_ and _User
     Filter_ settings described above will limit which users can use Forgejo and
-    which users will be synchronized. When initially run the task will create
-    all LDAP users that match the given settings so take care if working with
+    which users will be synchronized. When initially run, the task will create
+    all LDAP users that match the given settings, so take care if working with
     large Enterprise LDAP directories.
 
 ### LDAP using simple auth
@@ -112,7 +112,7 @@ Adds the following fields:
 - User DN **(required)**
 
   - A template to use as the user's DN. The `%s` matching parameter will be
-    substituted with login name given on sign-in form.
+    substituted with the login name given on the sign-in form.
   - Example: `cn=%s,ou=Users,dc=example,dc=com`
   - Example: `uid=%s,ou=Users,dc=example,dc=com`
 
@@ -123,7 +123,7 @@ Adds the following fields:
 
 - User Filter **(required)**
   - An LDAP filter declaring when a user should be allowed to log in. The `%s`
-    matching parameter will be substituted with login name given on sign-in
+    matching parameter will be substituted with the login name given on the sign-in
     form.
   - Example: `(&(objectClass=posixAccount)(|(cn=%[1]s)(mail=%[1]s)))`
   - Example: `(&(objectClass=posixAccount)(|(uid=%[1]s)(mail=%[1]s)))`
@@ -145,7 +145,7 @@ Uses the following fields:
 - User Attribute in Group (optional)
 
   - The user attribute that is used to reference a user in the group object.
-  - Example: `uid` if the group objects contains a `member: bender` and the user object contains a `uid: bender`.
+  - Example: `uid` if the group object contains a `member: bender` and the user object contains a `uid: bender`.
   - Example: `dn` if the group object contains a `member: uid=bender,ou=users,dc=planetexpress,dc=com`.
 
 - Group Attribute for User (optional)
@@ -171,33 +171,33 @@ built-in user manager.
    - Deselecting automatic sign-up may also be desired.
 1. Once the database has been initialized, log in as the newly created
    administrative user.
-1. Navigate to the user setting (icon in top-right corner), and select
+1. Navigate to the user settings (icon in the top-right corner), and select
    `Site Administration` -> `Authentication Sources`, and select
    `Add Authentication Source`.
-1. Fill out the field as follows:
-   - `Authentication Type` : `PAM`
-   - `Name` : Any value should be valid here, use "System Authentication" if
+1. Fill out the fields as follows:
+   - `Authentication Type`: `PAM`
+   - `Name`: Any value should be valid here; use "System Authentication" if
      you'd like.
-   - `PAM Service Name` : Select the appropriate file listed under `/etc/pam.d/`
+   - `PAM Service Name`: Select the appropriate file listed under `/etc/pam.d/`
      that performs the authentication desired.[^1]
-   - `PAM Email Domain` : The e-mail suffix to append to user authentication.
+   - `PAM Email Domain`: The e-mail suffix to append to user authentication.
      For example, if the login system expects a user called `gituser`, and this
      field is set to `mail.com`, then Forgejo will expect the `user email` field
      for an authenticated GIT instance to be `gituser@mail.com`.[^2]
 
-**Note**: PAM support is added via build-time flags (TAGS="pam" make build),
+**Note**: PAM support is added via build-time flags (`TAGS="pam" make build`),
 and the official binaries provided do not have this enabled. PAM requires that
-the necessary libpam dynamic library be available and the necessary PAM
+the necessary `libpam` dynamic library be available and the necessary PAM
 development headers be accessible to the compiler.
 
 [^1]:
     For example, using standard Linux log-in on Debian "Bullseye" use
     `common-session-noninteractive` - this value may be valid for other flavors of
-    Debian including Ubuntu and Mint, consult your distribution's documentation.
+    Debian including Ubuntu and Mint; consult your distribution's documentation.
 
 [^2]:
     **This is a required field for PAM**. Be aware: In the above example, the
-    user will log into the Forgejo web interface as `gituser` and not `gituser@mail.com`
+    user will log into the Forgejo web interface as `gituser` and not `gituser@mail.com`.
 
 ## FreeIPA
 
@@ -218,7 +218,7 @@ development headers be accessible to the compiler.
   nsIdleTimeout: 0
   ```
 
-- Import the LDIF (change localhost to an IPA server if needed). A prompt for
+- Import the LDIF (change localhost to an IPA server if needed). A prompt for the
   Directory Manager password will be presented:
 
   ```sh
@@ -226,7 +226,7 @@ development headers be accessible to the compiler.
   "cn=Directory Manager" -W -f forgejo.ldif
   ```
 
-- Add an IPA group for forgejo_users :
+- Add an IPA group for forgejo_users:
 
   ```sh
   ipa group-add --desc="Forgejo Users" forgejo_users
@@ -235,5 +235,5 @@ development headers be accessible to the compiler.
 - Note: For errors about IPA credentials, run `kinit admin` and provide the
   domain admin account password.
 
-- Log in to Forgejo as an Administrator and click on "Authentication" under Admin Panel.
+- Log in to Forgejo as an Administrator and click on "Authentication" under the Admin Panel.
   Then click `Add New Source` and fill in the details, changing all where appropriate.

docs/user/blame.md

@@ -4,15 +4,15 @@ license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/blame.en-us.md'
 ---
 
-Forgejo supports viewing the line-by-line revision history for a file also known as blame view.
+Forgejo supports viewing the line-by-line revision history for a file, also known as blame view.
 You can also use [`git blame`](https://git-scm.com/docs/git-blame) on the command line to view the revision history of lines within a file.
 
 ![Blame view of a file](../_images/user/blame/view.png)
 
 1. Navigate to and open the file whose line history you want to view.
-1. Click the `Blame` button in the file header bar.
-1. The new view shows the line-by-line revision history for a file with author and commit information on the left side.
-1. To navigate to an older commit, click the icon.
+2. Click the `Blame` button in the file header bar.
+3. The new view shows the line-by-line revision history for a file with author and commit information on the left side.
+4. To navigate to an older commit, click the icon.
 
 ## Ignore commits in the blame view
 
@@ -20,8 +20,8 @@ All revisions specified in the `.git-blame-ignore-revs` file are hidden from the
 This is especially useful to hide reformatting changes and keep the benefits of `git blame`.
 Lines that were changed or added by an ignored commit will be blamed on the previous commit that changed that line or nearby lines.
 The `.git-blame-ignore-revs` file must be located in the root directory of the repository.
-For more information like the file format, see [the `git blame --ignore-revs-file` documentation](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt).
+For more information, like the file format, see [the `git blame --ignore-revs-file` documentation](https://git-scm.com/docs/git-blame#Documentation/git-blame.txt---ignore-revs-fileltfilegt).
 
 ### Bypassing `.git-blame-ignore-revs` in the blame view
 
-If the blame view for a file shows a message about ignored revisions, you can see the normal blame view by appending the url parameter `?bypass-blame-ignore=true`.
+If the blame view for a file shows a message about ignored revisions, you can see the normal blame view by appending the URL parameter `?bypass-blame-ignore=true`.

docs/user/blocking-user.md

@@ -1,11 +1,11 @@
 ---
-title: Blocking a user
+title: Blocking a User
 license: 'CC-BY-SA-4.0'
 ---
 
-Blocking another user is desirable if they are acting maliciously or are spamming your repository (for instance by adding unsolicited comments in issues). For such cases, Forgejo provides the functionality to block other users. When you block a user, Forgejo does not explicitly notify them, but they may learn through an interaction with you that is blocked.
+Blocking another user is desirable if they are acting maliciously or are spamming your repository (for instance, by adding unsolicited comments in issues). For such cases, Forgejo provides the functionality to block other users. When you block a user, Forgejo does not explicitly notify them, but they may learn through an interaction with you that is blocked.
 
-## How to block someone
+## How to Block Someone
 
 In order to block another user, go to their profile page and click on the "Block" button.
 
@@ -15,7 +15,7 @@ A popup will show; please read carefully what blocking another user implies, and
 
 ![Popup where implications of the block action is listed](../_images/user/block/popup.png)
 
-### List of blocked users and unblocking
+### List of Blocked Users and Unblocking
 
 If you would like to see the list of users you've blocked, navigate to your user profile in the top-right corner and click on the settings item.
 
@@ -29,15 +29,15 @@ To unblock someone, click on the unblock button next to their name.
 
 ![List of people that are currently blocked by the user](../_images/user/block/user_list_blocks.png)
 
-## How to block someone as an organization
+## How to Block Someone as an Organization
 
-It is possible to block a user from an organization, this has the same implications as a normal user blocking another user. To block a user from an organization, you must be on that organization's Owners team.
+It is possible to block a user from an organization; this has the same implications as a normal user blocking another user. To block a user from an organization, you must be on that organization's Owners team.
 
 Navigate to your organization's settings and select the Blocked Users page.
 
 ![Blocked Users page being selected in the settings menu](../_images/user/block/org_page.png)
 
-Find the person you want to block in the search bar, select the user and click block.
+Find the person you want to block in the search bar, select the user, and click block.
 
 ![Search results being shown to the search query in the search bar](../_images/user/block/org_search.png)
 
@@ -49,19 +49,19 @@ To unblock that person, you can click the unblock button next to their name.
 
 ![Blocked person being shown in the blocked users list](../_images/user/block/org_unblock.png)
 
-## Implications of blocking a user
+## Implications of Blocking a User
 
 When you block a user:
 
 - You stop following them.
 - They stop following you.
 - They are removed as collaborators on repositories you own as an individual.
-- All pending repository transfers caused by the them are removed.
+- All pending repository transfers caused by them are removed.
 
 After you've blocked them:
 
 - They cannot cause any notifications for you anymore by mentioning you.
-- They cannot open issues or pull requests on repository you own.
+- They cannot open issues or pull requests on repositories you own.
 - They cannot add reactions to your comments.
-- They cannot post comments on issues and pull request you've opened.
+- They cannot post comments on issues and pull requests you've opened.
 - They cannot transfer repositories to you.

docs/user/code-search.md

@@ -21,13 +21,13 @@ The following options are currently available for code search while using `git-g
 
 ## Scope
 
-Since `git-grep` is performed on the fly, they can be executed on any valid branch or tag. The currently active branch/tag is displayed as the default value in the dropdown menu above the search bar, allowing users to easily switch between branches and tags.
+Since `git-grep` is performed on the fly, it can be executed on any valid branch or tag. The currently active branch/tag is displayed as the default value in the dropdown menu above the search bar, allowing users to easily switch between branches and tags.
 
-Searching within a specific directory (or file) executes `git-grep` using a [literal pathspec](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec) for the given path. If `REPO_INDEXER_INCLUDE` has been set by the administrator the filter is added if and only if it matches one of the globs.
+Searching within a specific directory (or file) executes `git-grep` using a [literal pathspec](https://git-scm.com/docs/gitglossary#Documentation/gitglossary.txt-aiddefpathspecapathspec) for the given path. If `REPO_INDEXER_INCLUDE` has been set by the administrator, the filter is added if and only if it matches one of the globs.
 
 ### Example
 
-Performing a search for `foo` at `/{user}/{repo}/src/branch/main/src` returns results that belong to the branch `main` inside the directory `/src`
+Performing a search for `foo` at `/{user}/{repo}/src/branch/main/src` returns results that belong to the branch `main` inside the directory `/src`.
 
 ```
 main
@@ -37,7 +37,7 @@ main
     └── utils.go
 ```
 
-In the above figure the search would matches results for `foo`, in `main.go` and `utils.go`, but not from `docs/*`.
+In the above figure, the search would match results for `foo` in `main.go` and `utils.go`, but not from `docs/*`.
 
 # Indexer
 
@@ -50,7 +50,7 @@ For complex searches or cross-repository queries across an entire organization o
 The following options are currently available for code search while using an indexer.
 
 - **Exact**: Perform an exact match on the provided expression.
-- **Fuzzy**: Conduct a fuzzy search, returning results that contain the keyword within a maximum edit-distance of 2. For example, a search query containing `hello` will yield results with
+- **Fuzzy**: Conduct a fuzzy search, returning results that contain the keyword within a maximum edit distance of 2. For example, a search query containing `hello` will yield results with:
   - **edit distance of 0**: `hello`
   - **edit distance of 1**: For example, `hllo` (delete), `helloo` (add), `hallo` (modify).
 
@@ -58,4 +58,4 @@ The following options are currently available for code search while using an ind
 
 Please note that when using the repository indexer, search results are limited to the contents of the HEAD branch of each repository.
 
-Similar to basic search, searching within a directory (or file) is also possible for advanced search. However, unlike basic search the search is more granular as it applies the filter, but selectively includes/excludes files depending on `REPO_INDEXER_INCLUDE`/`REPO_INDEXER_EXCLUDE`
+Similar to basic search, searching within a directory (or file) is also possible for advanced search. However, unlike basic search, the search is more granular as it applies the filter but selectively includes/excludes files depending on `REPO_INDEXER_INCLUDE`/`REPO_INDEXER_EXCLUDE`.

docs/user/email-settings.md

@@ -8,7 +8,7 @@ origin_title: 'Email Settings'
 
 By default, Forgejo will send notifications to your registered email addresses.
 
-This section only concerns your Forgejo account and will not affect the commits you do not make on the website.
+This section only concerns your Forgejo account and will not affect the commits you make outside the website.
 If you don't know how to **configure your name and email in Git**, take a look at the ["Configuring Git" man page](https://git-scm.com/docs/git-config).
 
 ## Configuring all notifications
@@ -33,7 +33,7 @@ When you're finished, press the button “Set Email Preference” to confirm you
 
 ## Issue notifications
 
-As soon as you make a comment on an issue, you automatically subscribe to it. Unless you disabled email notifications for all your email addresses, you will get an email for every change and comment on that issue.
+As soon as you make a comment on an issue, you automatically subscribe to it. Unless you have disabled email notifications for all your email addresses, you will get an email for every change and comment on that issue.
 
 You can check and modify your issue subscription status under the “Notifications” section on the menu on the right side of the issue screen.
 
@@ -43,4 +43,4 @@ When you watch a repository (by clicking on the “Watch” button in a reposito
 
 To stop watching a repository, simply click on “Unwatch” in a repository.
 
-To list all of your watched repositories, click on `/notifications/watching`. Alternatively you can click the menu button “Profile and Settings...” in the top-right corner of Forgejo and click on "Subscriptions" in the dropdown.
+To list all of your watched repositories, click on `/notifications/watching`. Alternatively, you can click the menu button “Profile and Settings...” in the top-right corner of Forgejo and click on "Subscriptions" in the dropdown.

docs/user/first-repository.md

@@ -8,52 +8,52 @@ origin_title: 'Your First Repository'
 
 Almost everything on Forgejo happens in a repository. Think of a repository as a home for your project, where all of its source code can be organized using Git, as well as where you can track issues and read and write wikis.
 
-This article will guide you through creating your first repository on Forgejo, connecting your local development environment and making your first commit.
+This article will guide you through creating your first repository on Forgejo, connecting your local development environment, and making your first commit.
 
 ## Creating a Repository
 
-To create a new repository, you need be logged in to your account.
+To create a new repository, you need to be logged in to your account.
 
-When you're logged in, you can use one of the two buttons shown in the two following screenshots to create a new repository:
+When you're logged in, you can use one of the two buttons shown in the following screenshots to create a new repository:
 
 ![screenshot of the expanded menu in the upper right corner to create a new repository](../_images/user/first-repository/create-repo.png)
 
-This will lead you to this page below.
+This will lead you to the page below.
 
 ![screenshot of new repository page](../_images/user/first-repository/create-repo-2.png)
 
 Here's an explanation of the form's fields:
 
-- **Owner** Here, you can specify whether you want this to be your own personal project or whether you want it to be part of an organization that you're a part of
-- **Repository name** A name for your repository (which will also be part of its path, in this case `https://codeberg.org/knut/foobar`)
-- **Visibility** Repositories are either _public_ or _private_, where public means that everyone will be able to access your repository, while your private repositories can only be accessed by you and your collaborators (see [Invite Collaborators](https://docs.codeberg.org/collaborating/invite-collaborators/))
-- **Description** A short description that appears next to your repository's name where appropriate
-- **Template** Occasionally you may want to generate your repository from an existing template. In that case, you can specify that template here. Otherwise, simply leave this field empty.
-- **Issue Labels** If you want to initialize your project's issue tracker with a set of labels that you can use to categorize issues, you can choose one here. You don't have to choose this right away though, as you can choose and modify issue labels at a later time as well.
-- **.gitignore** A [.gitignore](https://git-scm.com/docs/gitignore) file defines which files Git should not keep track of. This is useful, for example to prevent configuration files or binaries to be tracked in version control. You can choose to add a predefined file matching the programming language you use now, or add one manually later.
+- **Owner** Here, you can specify whether you want this to be your own personal project or whether you want it to be part of an organization that you're a part of.
+- **Repository name** A name for your repository (which will also be part of its path, in this case `https://codeberg.org/knut/foobar`).
+- **Visibility** Repositories are either _public_ or _private_. Public means that everyone will be able to access your repository, while your private repositories can only be accessed by you and your collaborators (see [Invite Collaborators](https://docs.codeberg.org/collaborating/invite-collaborators/)).
+- **Description** A short description that appears next to your repository's name where appropriate.
+- **Template** Occasionally, you may want to generate your repository from an existing template. In that case, you can specify that template here. Otherwise, simply leave this field empty.
+- **Issue Labels** If you want to initialize your project's issue tracker with a set of labels that you can use to categorize issues, you can choose one here. You don't have to choose this right away, though, as you can choose and modify issue labels at a later time as well.
+- **.gitignore** A [.gitignore](https://git-scm.com/docs/gitignore) file defines which files Git should not keep track of. This is useful, for example, to prevent configuration files or binaries from being tracked in version control. You can choose to add a predefined file matching the programming language you use now, or add one manually later.
 - **License** Here, you can choose from a list of FSF/OSI approved licenses. A `LICENSE` file will then be added to the repository. For some help on choosing the correct license, have a look at our [licensing article](https://docs.codeberg.org/getting-started/licensing/).
 - **README** is the first file one should read when accessing a repository. It's also the first file displayed when accessing a repository, a bit like the "homepage" of your repository. On Forgejo, this is interpreted as a [Markdown](https://docs.codeberg.org/markdown/) file.
-- **Initialize repository** In order to add the `LICENSE`, `README` and `.gitignore` files mentioned above to your new repository, make sure you tick this box.
+- **Initialize repository** In order to add the `LICENSE`, `README`, and `.gitignore` files mentioned above to your new repository, make sure you tick this box.
 - **Default branch** Using this field, you can choose how to name the default branch of your Git repository. We recommend you use the predefined default.
 - **Object format** is the repository's object format. We recommend SHA1 as it's the most compatible. It cannot be changed later once the repository has been created.
 
-It's okay to only specify owner and repository name, if you want to get started quickly.
-After filling out the fields, click the green "Create Repository" button on the bottom of the page.
+It's okay to only specify the owner and repository name if you want to get started quickly.
+After filling out the fields, click the green "Create Repository" button at the bottom of the page.
 
-You should now see a screen similar to the one below. If you haven't chosen to generate `LICENSE`, `README` and `.gitignore` the screen might show instructions instead, which will vanish after [your first commit](#making-your-first-commit).
+You should now see a screen similar to the one below. If you haven't chosen to generate `LICENSE`, `README`, and `.gitignore`, the screen might show instructions instead, which will vanish after [your first commit](#making-your-first-commit).
 
 ![screenshot showing a freshly baked repository](../_images/user/first-repository/create-repo-3.png)
 
 Here's what the most important buttons do:
 
-- **Repository Settings (1)** is where you can make adjustments to your repository settings, such as setting a project website, changing the repository description, enabling/disabling a wiki and issue tracker or deleting the repository. You may want to give this page a visit right now, to get an overview of your options.
-- **The RSS, Watch, Star and Fork buttons (2)** allow you to interact with other people's repositories. While they don't do much for your own repository, when visiting another user's repository, you can click on "Watch" to get notified about everything important happening in that repository, "Star" to show the user your appreciation (and to help other users find interesting projects more quickly) and "Fork" to create your own copy of the repository, for example to make modifications that you want to share with the original author. You can also use the RSS button to get the RSS feed of the repository.
+- **Repository Settings (1)** is where you can make adjustments to your repository settings, such as setting a project website, changing the repository description, enabling/disabling a wiki and issue tracker, or deleting the repository. You may want to give this page a visit right now to get an overview of your options.
+- **The RSS, Watch, Star, and Fork buttons (2)** allow you to interact with other people's repositories. While they don't do much for your own repository, when visiting another user's repository, you can click on "Watch" to get notified about everything important happening in that repository, "Star" to show the user your appreciation (and to help other users find interesting projects more quickly), and "Fork" to create your own copy of the repository, for example, to make modifications that you want to share with the original author. You can also use the RSS button to get the RSS feed of the repository.
 - **The Repository Tabs (3)** contain links to every important feature within this repository (some may not be visible by default):
   - **Code** lets you browse through all versions of this repository's code.
-  - **Issues** is a very important communication tool between the author, their users and their contributors. Think of it as part bug-tracker, part forum.
-    For more information on this, have a look at [The Basics of Issue Tracking](../issue-tracking-basics/)
+  - **Issues** is a very important communication tool between the author, their users, and their contributors. Think of it as part bug-tracker, part forum.
+    For more information on this, have a look at [The Basics of Issue Tracking](../issue-tracking-basics/).
   - **Pull Requests** is where other users can ask the author to "pull" in code, from a fork into the author's program.
-  - **Releases** is a space where the author can upload finished versions of their program, e.g. binaries
+  - **Releases** is a space where the author can upload finished versions of their program, e.g., binaries.
   - **Wiki** is a basic wiki feature built into Forgejo.
   - **Activity** calculates statistics about this repository.
 - **Repository's Git URLs (4)** - use these to let Git know where to find this repository. Don't worry if you don't understand this now - we will look at this in the following section.
@@ -67,7 +67,7 @@ In this guide, we'll focus on connecting to Forgejo via HTTP using Git on the co
 - [Clone & Commit via CLI](https://docs.codeberg.org/git/clone-commit-via-cli/) and
 - [Clone & Commit via Web](https://docs.codeberg.org/git/clone-commit-via-web/)
 
-> Although we use HTTP in this guide, it is a good idea to setup SSH-based authentication once you feel confident to do so.
+> Although we use HTTP in this guide, it is a good idea to set up SSH-based authentication once you feel confident to do so.
 
 ### Option A: Clone the newly created, empty repository
 
@@ -111,7 +111,7 @@ LICENSE  README.md
 
 ### Option B: Connect an existing local source tree
 
-If you already have written source code that you now would like to upload to Forgejo, follow these steps:
+If you have already written source code that you now would like to upload to Forgejo, follow these steps:
 
 #### 1. Initialize a Git Repository
 
@@ -161,7 +161,7 @@ knut@iceberg:~/repositories/foobar$ cat README.md
 Hello World!
 ```
 
-Now, if you now ask Git about your repository's status, you should see something similar to this:
+Now, if you ask Git about your repository's status, you should see something similar to this:
 
 ```bash
 knut@iceberg:~/repositories/foobar$ git status
@@ -192,7 +192,7 @@ This command should output nothing.
 
 #### 3. Commit your changes
 
-By committing your changes, you create a new step in the version history of your program. They act like snapshots of your program's state at a given point of time, and you will later be able to jump back and forth between them.
+By committing your changes, you create a new step in the version history of your program. They act like snapshots of your program's state at a given point in time, and you will later be able to jump back and forth between them.
 
 > It is recommended to keep commits small and focused, so that, if necessary, they can be reverted or easily adapted into another context without too many side-effects.
 

docs/user/incoming.md

@@ -3,16 +3,16 @@ title: Comment on issues and pull requests via email
 license: 'CC-BY-SA-4.0'
 ---
 
-> **NOTE:** this feature is not enabled by default, the [`[email.incoming].ENABLED`](../../admin/config-cheat-sheet/) setting must be set.
+> **NOTE:** This feature is not enabled by default; the [`[email.incoming].ENABLED`](../../admin/config-cheat-sheet/) setting must be set.
 
-When receiving a notification it is possible to reply to the email instead of using the web interface. The content of the reply will be stripped of the quoted text (lines starting with greater than `>`) and used as the content of the comment. The attachments from the reply will be added as attachments to the comment.
+When receiving a notification, it is possible to reply to the email instead of using the web interface. The content of the reply will be stripped of the quoted text (lines starting with a greater than `>`) and used as the content of the comment. The attachments from the reply will be added as attachments to the comment.
 
 It will be taken into account when receiving a notification email about:
 
 - A newly created issue
 - A newly created pull request
 - A comment added to a specific line of code in a pull request review
-- A comment to an existing issue
-- A comment to an existing pull request
+- A comment on an existing issue
+- A comment on an existing pull request
 
-> **NOTE:** the reply address contains a unique token to match the response with the issue or pull request and looks like this: `forgejo+ABCDE@example.com`. In some mail clients, such as Thunderbird, using this reply address may require using the `Reply List` button rather than the `Reply` button.
+> **NOTE:** The reply address contains a unique token to match the response with the issue or pull request and looks like this: `forgejo+ABCDE@example.com`. In some mail clients, such as Thunderbird, using this reply address may require using the `Reply List` button rather than the `Reply` button.

docs/user/issue-pull-request-templates.md

@@ -7,7 +7,7 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
 Some projects have a standard list of questions that users need to answer
 when creating an issue or pull request. Forgejo supports adding templates to the
 **default branch of the repository** so that they can autopopulate the form when users are
-creating issues and pull requests. This will cut down on the initial back and forth
+creating issues and pull requests. This will cut down on the initial back-and-forth
 of getting some clarifying details.
 It is currently not possible to provide generic issue/pull-request templates globally.
 

docs/user/issue-search.md

@@ -3,7 +3,7 @@ title: Issue Search
 license: 'CC-BY-SA-4.0'
 ---
 
-Since v11, Issue search on Forgejo replaced it's previously dropdown defined behaviour of searches with a query syntax defined by operators.
+Since v11, Issue search on Forgejo replaced its previously dropdown-defined behavior of searches with a query syntax defined by operators.
 
 ## Query Syntax
 
@@ -15,8 +15,8 @@ Performs a fuzzy match search of each term in the query.
 
 For example,
 
-- `foo` will return results that contain `foo`, or any of it's derivatives (such as `for` or `food`)
-- `foo bar` will return results that contain `foo` and/or `bar` or any of it's derivatives
+- `foo` will return results that contain `foo`, or any of its derivatives (such as `for` or `food`)
+- `foo bar` will return results that contain `foo` and/or `bar` or any of their derivatives
 
 2. Phrase
 
@@ -31,16 +31,16 @@ For example,
 
 1. Negation
 
-Negates the keyword by returning results that does not contain the keyword. This is done by prefixing the keyword with a minus symbol.
+Negates the keyword by returning results that do not contain the keyword. This is done by prefixing the keyword with a minus symbol.
 
 For example,
 
-- `-foo` will return results that does not contain `foo` or it's derivatives
-- `-"foo bar"` will return results that does not contain `foo bar`
+- `-foo` will return results that do not contain `foo` or its derivatives
+- `-"foo bar"` will return results that do not contain `foo bar`
 
 2. Required
 
-Denotes that the provided keyword MUST be present. This is done by prefixing the keyword with with a plus symbol.
+Denotes that the provided keyword MUST be present. This is done by prefixing the keyword with a plus symbol.
 
 For example,
 

docs/user/issue-tracking-basics.md

@@ -6,10 +6,10 @@ origin_author: 'Codeberg Docs Contributors'
 origin_title: 'The Basics of Issue Tracking'
 ---
 
-Issues are an important mean of communication on Forgejo.
+Issues are an important means of communication on Forgejo.
 Besides their original purpose - reporting bugs to a project's maintainer -
 they can be used to suggest enhancements, ask for new features, discuss a project's
-direction, ask questions and much more.
+direction, ask questions, and much more.
 
 ## The Issue Tracker
 
@@ -21,7 +21,7 @@ There, you'll see a browsable and filterable **(2)** list of all issues.
 Many projects use labels to categorize issues. If you want to contribute to a project,
 a good label to look for is the "help wanted" label.
 
-You can switch between issues that are still open, and those that are already resolved **(3)**.
+You can switch between issues that are still open and those that are already resolved **(3)**.
 
 Some projects define milestones **(4)**, to which issues can be assigned. They are good for
 visualizing the progress of a project's development.
@@ -38,11 +38,11 @@ list.
 ## Life of an Issue
 
 Once an issue in the Issue Tracker has been created, it will usually pass through a
-process of review, discussion and closure, which can be more or less strictly defined,
+process of review, discussion, and closure, which can be more or less strictly defined,
 based on the project you're contributing to.
 
 The first thing that might happen is that your issue is categorized using labels.
-Your issue may be reviewed by the project's maintainer(s) and evaluated whether it, i.e., is a bug report or feature request.
+Your issue may be reviewed by the project's maintainer(s) and evaluated whether it is, i.e., a bug report or feature request.
 
 Then, depending on what type of issue it is, there might be additional questions
 or a discussion and, if applicable, the implementation of a solution (or the rejection of
@@ -59,15 +59,15 @@ something to them).
 > If you encounter an abandoned project and there's no way of contacting the maintainer(s),
 > consider forking it, if you want to assume responsibility for it (or, rather, your fork).
 
-## Things to consider
+## Things to Consider
 
 ### Security bugs
 
 If the bug you have found has security implications, **do not create
-an issue right away!** Instead try contacting the project's maintainers privately.
-Many projects have a dedicated e-mail address for reporting security bugs. If the
+an issue right away!** Instead, try contacting the project's maintainers privately.
+Many projects have a dedicated email address for reporting security bugs. If the
 project in question doesn't, consider writing an email directly to the project's
-maintainer or ask for the address in the issue tracker.
+maintainer or asking for the address in the issue tracker.
 
 > **⚠** What's important is that you **don't publicly expose security bugs before they are
 > fixed _and_ the fixes are deployed**, because **otherwise, you might put the users of that

docs/user/labels.md

@@ -4,7 +4,7 @@ license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/labels.en-us.md'
 ---
 
-You can use labels to classify issues and pull requests and to improve your overview over them.
+You can use labels to classify issues and pull requests and to improve your overview of them.
 
 Labels can be created by going to the `Issues` page of a repository and clicking on `Labels` to show the labels management page.
 
@@ -20,7 +20,7 @@ From the labels management page, click on the `New Label` button.
 
 ![create a label](../_images/user/labels/label-new.png)
 
-Labels have a mandatory name, a mandatory color, an optional description, and must either be exclusive or not (see `Scoped labels` below).
+Labels have a mandatory name, a mandatory color, an optional description, and must either be exclusive or not (see `Scoped Labels` below).
 
 When you create a repository (or an organization), you can ensure certain labels exist by using the `Issue Labels` option. This option lists a number of available label sets that are configured globally on your instance.
 
@@ -30,7 +30,7 @@ When a label is no longer useful but needs to be kept around because
 it is still associated with existing pull requests or issues, it can be archived.
 
 - The label won't show up as a suggestion when you're adding/editing labels.
-- The label cannot be assigned to a new issues or pull requests.
+- The label cannot be assigned to new issues or pull requests.
 
 To archive a label, edit the label and click the `Archive` checkbox.
 
@@ -44,7 +44,7 @@ Scoped labels are used to ensure at most a single label with the same scope is a
 
 A scoped label must contain `/` in its name (not at either end of the name). The scope of a label is determined based on the **last** `/`, so for example the scope of label `scope/subscope/item` is `scope/subscope`.
 
-## Applying labels
+## Applying Labels
 
 Labels can be applied to issues or pull requests on their pages by clicking on `Labels`. In the dropdown menu, labels can be added or removed. Of a set of scoped labels with the same scope, only one can be selected. Archived labels are disabled for addition.
 
@@ -54,4 +54,4 @@ Labels can be applied to issues or pull requests on their pages by clicking on `
 
 Issue and pull request lists can be filtered by label. Selecting multiple labels shows issues and pull requests that have all selected labels assigned.
 
-By holding alt to click the label, issues and pull requests with the chosen label are excluded from the list.
+By holding alt and clicking the label, issues and pull requests with the chosen label are excluded from the list.

docs/user/language-detection.md

@@ -7,7 +7,7 @@ Forgejo tries to detect the languages used in a repository, for each file, to us
 
 ![Repository language statistics](../_images/user/language-detection/repo-languages.png)
 
-This comes with sensible defaults that should work for most cases, but it is not without faults or compromises, and there are scenarios where the detection needs a little guidance. Further below, we will explain how it can be influenced, but lets look at the defaults first!
+This comes with sensible defaults that should work for most cases, but it is not without faults or compromises, and there are scenarios where the detection needs a little guidance. Further below, we will explain how it can be influenced, but let's look at the defaults first!
 
 ## Built-in language detection
 
@@ -32,7 +32,7 @@ While some of the categories are rather straightforward, a little explanation ab
 
 **Dotfiles** are files whose name starts with a dot, which by convention, suggests they should be hidden, and as such, they are excluded from language statistics.
 
-**Programming languages** and **Markup languages** are more or less self explanatory. The former category includes languages like C, Go, Rust, JavaScript, and many, many others. Markup languages are CSS, HTML, Jinja templates, Jupyter Notebooks, and numerous other formats.
+**Programming languages** and **Markup languages** are more or less self-explanatory. The former category includes languages like C, Go, Rust, JavaScript, and many, many others. Markup languages are CSS, HTML, Jinja templates, Jupyter Notebooks, and numerous other formats.
 
 Please consult the [enry][enry] or [linguist][linguist] documentation for more details.
 

docs/user/linked-references.md

@@ -1,11 +1,11 @@
 ---
-title: 'Automatically Linked References in Issues, Pull Requests and Commit Messages'
+title: 'Automatically Linked References in Issues, Pull Requests, and Commit Messages'
 license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/linked-references.en-us.md'
 ---
 
-When an issue, pull request or comment is posted, the text description is parsed
-in search for references. These references will be shown as links in the Issue View
+When an issue, pull request, or comment is posted, the text description is parsed
+in search of references. These references will be shown as links in the Issue View
 and, in some cases, produce certain _actions_.
 
 Likewise, commit messages are parsed when they are listed, and _actions_
@@ -13,14 +13,14 @@ can be triggered when they are pushed.
 
 To prevent the creation of unintended references, there are certain rules
 for them to be recognized. For example, they should not be included inside code
-text. They should also be reasonably cleared from their surrounding text
+text. They should also be reasonably clear from their surrounding text
 (for example, using spaces).
 
-## User, Team and Organization Mentions
+## User, Team, and Organization Mentions
 
-When a text in the form `@username` is found and `username` matches the name
+When text in the form `@username` is found and `username` matches the name
 of an existing user, a _mention_ reference is created. This will be shown
-by changing the text into a link to said user's profile, and possibly create
+by changing the text into a link to said user's profile, and possibly creating
 a notification for the mentioned user depending on whether they have
 the necessary permission to access the contents.
 
@@ -33,7 +33,7 @@ This is also valid for teams and organizations:
 > [@Documenters](#), we need to plan for this.
 > [@CoolCompanyInc](#), this issue concerns us all!
 
-Teams will receive mail notifications when appropriate, but whole organizations won't.
+Teams will receive email notifications when appropriate, but whole organizations won't.
 
 Commit messages do not produce user notifications.
 
@@ -47,27 +47,27 @@ Example:
 
 > This bug was introduced in [e59ff077](#)
 
-## Code references
+## Code References
 
-It is possible to reference any portion of a file in a repository, by using the permalink feature inside the file viewer:
+It is possible to reference any portion of a file in a repository by using the permalink feature inside the file viewer:
 
 ![Permalinking of a line range](../_images/user/linked-references/permalink-coderange.png)
 
-If used inside a issue or pull request, this is automatically rendered into a inline preview of the portion of that file.
+If used inside an issue or pull request, this is automatically rendered into an inline preview of the portion of that file.
 
-> **NOTE:** Alternatively, you also can use the "Reference in a new issue" action to automatically create an issue with the correct permalink.
+> **NOTE:** Alternatively, you can also use the "Reference in a new issue" action to automatically create an issue with the correct permalink.
 
 Example:
 
-> See the code here: https://next.forgejo.org/Mai-Lapyst/test/src/commit/66719555bd242b9ad7c3fb9eef2b388826d87872/hook.go#L191-L200 It set's all of the options for this.
+> See the code here: https://next.forgejo.org/Mai-Lapyst/test/src/commit/66719555bd242b9ad7c3fb9eef2b388826d87872/hook.go#L191-L200 It sets all of the options for this.
 
-![Rendered result of an permalink code reference](../_images/user/linked-references/rendered-permalink.png)
+![Rendered result of a permalink code reference](../_images/user/linked-references/rendered-permalink.png)
 
 There are some restrictions in place:
 
 - Code linked in private repositories will not be displayed if the current viewer has insufficient permissions.
-- It can only ever be a permalink; means linking to files by a branch or tag will not result in a preview.
-- There is a maximum amount of lines that will be rendered. By default this is 50.
+- It can only ever be a permalink; linking to files by a branch or tag will not result in a preview.
+- There is a maximum amount of lines that will be rendered. By default, this is 50.
 - Only permalinks to the current instance will work.
 
 ## Issues and Pull Requests
@@ -134,13 +134,13 @@ The default _keywords_ are:
 - **Closing**: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved
 - **Reopening**: reopen, reopens, reopened
 
-## Time tracking in Pull Requests and Commit Messages
+## Time Tracking in Pull Requests and Commit Messages
 
-When commit or merging of pull request results in automatic closing of issue
-it is possible to also add spent time resolving this issue through commit message.
+When a commit or merging of a pull request results in automatic closing of an issue,
+it is possible to also add the spent time resolving this issue through the commit message.
 
-To specify spent time on resolving issue you need to specify time in format
-`@<number><time-unit>` after issue number. In one commit message you can specify
+To specify spent time on resolving an issue, you need to specify time in the format
+`@<number><time-unit>` after the issue number. In one commit message, you can specify
 multiple fixed issues and spent time for each of them.
 
 Supported time units (`<time-unit>`):
@@ -151,15 +151,15 @@ Supported time units (`<time-unit>`):
 - `w` - weeks (equals to 5 days)
 - `mo` - months (equals to 4 weeks)
 
-Numbers to specify time (`<number>`) can be also decimal numbers, ex. `@1.5h` would
-result in one and half hours. Multiple time units can be combined, ex. `@1h10m` would
+Numbers to specify time (`<number>`) can be also decimal numbers, e.g., `@1.5h` would
+result in one and a half hours. Multiple time units can be combined, e.g., `@1h10m` would
 mean 1 hour and 10 minutes.
 
 Example of commit message:
 
 > Fixed #123 spent @1h, refs #102, fixes #124 @1.5h
 
-This would result in 1 hour added to issue #123 and 1 and half hours added to issue #124.
+This would result in 1 hour added to issue #123 and 1 and a half hours added to issue #124.
 
 ## External Trackers
 
@@ -172,9 +172,9 @@ the `!` marker to identify pull requests. For example:
 > This is issue [#1234](#), and links to the external tracker.
 > This is pull request [!1234](#), and links to a pull request in Forgejo.
 
-The `!` and `#` can be used interchangeably for issues and pull request _except_
-for this case, where a distinction is required. If the repository uses external
-tracker, commit message for squash merge will use `!` as reference by default.
+The `!` and `#` can be used interchangeably for issues and pull requests _except_
+for this case, where a distinction is required. If the repository uses an external
+tracker, the commit message for a squash merge will use `!` as a reference by default.
 
 ## Issues and Pull Requests References Summary
 
@@ -203,7 +203,7 @@ In the examples, `User1/Repo1` refers to the repository where the reference is u
 | _Not supported_             |             -             |            yes            | A link to _external issue_ `AAA-1234` for `UserZ/RepoZ` |
 | `UserZ/RepoZ!1234`          |             -             |            yes            | A link to _PR_ 1234 in `UserZ/RepoZ`                    |
 
-_The last section is for repositories with external issue trackers that use alphanumeric format._
+_The last section is for repositories with external issue trackers that use an alphanumeric format._
 
 _**-**: not applicable._
 

docs/user/merge-message-templates.md

@@ -1,10 +1,10 @@
 ---
-title: 'Merge Message templates'
+title: 'Merge Message Templates'
 license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/merge-message-templates.en-us.md'
 ---
 
-## File names
+## File Names
 
 Possible file names for PR default merge message templates:
 
@@ -15,11 +15,11 @@ Possible file names for PR default merge message templates:
 - `.forgejo/default_merge_message/MANUALLY-MERGED_TEMPLATE.md`
 - `.forgejo/default_merge_message/REBASE-UPDATE-ONLY_TEMPLATE.md`
 
-Note: `.gitea` as the root directory is also recognised and kept only for compatibility reasons.
+Note: `.gitea` as the root directory is also recognized and kept only for compatibility reasons.
 
 ## Variables
 
-You can use the following variables enclosed in `${}` inside these templates which follow [os.Expand](https://pkg.go.dev/os#Expand) syntax:
+You can use the following variables enclosed in `${}` inside these templates, which follow [os.Expand](https://pkg.go.dev/os#Expand) syntax:
 
 - BaseRepoOwnerName: Base repository owner name of this pull request
 - BaseRepoName: Base repository name of this pull request
@@ -31,8 +31,8 @@ You can use the following variables enclosed in `${}` inside these templates whi
 - PullRequestDescription: Pull request's description
 - PullRequestPosterName: Pull request's poster name
 - PullRequestIndex: Pull request's index number
-- PullRequestReference: Pull request's reference char with index number. i.e. #1, !2
-- ClosingIssues: return a string contains all issues which will be closed by this pull request i.e. `close #1, close #2`
+- PullRequestReference: Pull request's reference character with index number, i.e., #1, !2
+- ClosingIssues: Returns a string containing all issues that will be closed by this pull request, i.e., `close #1, close #2`
 
 ## Rebase
 

docs/user/oauth2-provider.md

@@ -6,11 +6,11 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
 
 Forgejo supports acting as an OAuth2 provider to allow third party applications to access its resources with the user's consent.
 
-> **NOTE:** scoped tokens or personal access tokens are entirely different from OAuth2, see the [Access Token scope](../token-scope/) section for more information.
+> **NOTE:** Scoped tokens or personal access tokens are entirely different from OAuth2; see the [Access Token scope](../token-scope/) section for more information.
 
-Forgejo can act as an instance wide OAuth2 provider. To achieve that, OAuth2 applications must be created in the `/admin/applications` page.
+Forgejo can act as an instance-wide OAuth2 provider. To achieve that, OAuth2 applications must be created on the `/admin/applications` page.
 
-> **NOTE:** Third party applications obtaining a token for a user via such an application will have administrative rights. OAuth2 scopes are not yet implemented.
+> **NOTE:** Third-party applications obtaining a token for a user via such an application will have administrative rights. OAuth2 scopes are not yet implemented.
 
 ## Endpoints
 
@@ -24,12 +24,12 @@ Forgejo can act as an instance wide OAuth2 provider. To achieve that, OAuth2 app
 
 ## Supported OAuth2 Grants
 
-At the moment Forgejo only supports the [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) standard with additional support of the following extensions:
+At the moment, Forgejo only supports the [**Authorization Code Grant**](https://tools.ietf.org/html/rfc6749#section-1.3.1) standard with additional support for the following extensions:
 
 - [Proof Key for Code Exchange (PKCE)](https://tools.ietf.org/html/rfc7636)
 - [OpenID Connect (OIDC)](https://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth)
 
-To use the Authorization Code Grant as a third party application it is required to register a new application via the "Settings" (`/user/settings/applications`) section of the settings. To test or debug you can use the web-tool https://oauthdebugger.com/.
+To use the Authorization Code Grant as a third-party application, it is required to register a new application via the "Settings" (`/user/settings/applications`) section. To test or debug, you can use the web tool https://oauthdebugger.com/.
 
 ## Client types
 
@@ -40,7 +40,7 @@ For public clients, a redirect URI of a loopback IP address such as `http://127.
 ## Git authentication
 
 OAuth2 can be used as an alternative to a public SSH key or basic authentication (user/password) to obtain the required
-read or write access permissions. It relies on a Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers)
+read or write access permissions. It relies on Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers)
 such as:
 
 - [Git Credential Manager](https://github.com/git-ecosystem/git-credential-manager)
@@ -66,49 +66,49 @@ to authenticate on https://code.forgejo.org:
     oauthTokenURL = /login/oauth/access_token
   ```
 - `git clone https://code.forgejo.org/earl-warren/test`
-- `git push` will open new page on the default browser, looking like this:
+- `git push` will open a new page on the default browser, looking like this:
   ![git-credential-oauth OAuth2 grant page](../_images/user/oauth2-provider/oauth-git-credential-client.png)
-- subsequent `git push` will reuse the token obtained from OAuth2 as long as it remains in the [git credential-cache](https://git-scm.com/docs/git-credential-cache) (i.e. 2h / 7200s)
+- subsequent `git push` will reuse the token obtained from OAuth2 as long as it remains in the [git credential-cache](https://git-scm.com/docs/git-credential-cache) (i.e., 2h / 7200s)
 
-> **NOTE:** Scopes are not implemented for OAuth2 tokens and they can be used to execute any actions on behalf the user, not just git related actions. Scoped applications tokens or SSH keys limited to interactions with the repository should be preferred in environments where security is a concern.
+> **NOTE:** Scopes are not implemented for OAuth2 tokens and they can be used to execute any actions on behalf of the user, not just Git-related actions. Scoped application tokens or SSH keys limited to interactions with the repository should be preferred in environments where security is a concern.
 
-It is possible for any user to manually register a new OAuth2 application in the `/user/settings/applications` page for the purpose of using a Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers) different from the pre-registered ones. In that case the `~/.gitconfig` setting (`oauthClientId` etc.) needs to be adapted accordingly
+It is possible for any user to manually register a new OAuth2 application on the `/user/settings/applications` page for the purpose of using Git [credential helpers](https://git-scm.com/docs/gitcredentials#_custom_helpers) different from the pre-registered ones. In that case, the `~/.gitconfig` setting (`oauthClientId`, etc.) needs to be adapted accordingly.
 
 ## Examples
 
 ### Using Codeberg as an authentication source
 
-In this example https://v7.next.forgejo.org will be configured to add the option to delegate user registration to https://codeberg.org.
+In this example, https://v7.next.forgejo.org will be configured to add the option to delegate user registration to https://codeberg.org.
 
 ![Login page with Codeberg authentication source](../_images/user/oauth2-provider/authsource-intro-login-page.png)
 
-> **NOTE:** in the OAuth2 jargon, https://v7.next.forgejo.org is the OAuth2 client and Codeberg is the OAuth2 provider
+> **NOTE:** In OAuth2 jargon, https://v7.next.forgejo.org is the OAuth2 client and Codeberg is the OAuth2 provider.
 
-- Choose an arbitrary but distinctive name for the OAuth2 provider: (e.g. **Codeberg**).
-- Choose an existing Codeberg user to create the OAuth2 application. It does not need to be a user with elevated privileges. (e.g. **user-for-oauth-application**)
-- On https://codeberg.org, login as **user-for-oauth-application**
+- Choose an arbitrary but distinctive name for the OAuth2 provider (e.g., **Codeberg**).
+- Choose an existing Codeberg user to create the OAuth2 application. It does not need to be a user with elevated privileges (e.g., **user-for-oauth-application**).
+- On https://codeberg.org, log in as **user-for-oauth-application**.
   - Visit https://codeberg.org/user/settings/applications and create a new OAuth2 application. There needs to be only one redirect URI, composed with the arbitrary name that was chosen above: https://v7.next.forgejo.org/user/oauth2/Codeberg/callback.
     ![Create a new OAuth2 application](../_images/user/oauth2-provider/authsource-provider-create.png)
   - When created, the OAuth2 application is given a **Client ID** and a **Client secret** that https://v7.next.forgejo.org will need to let https://codeberg.org know it is an authorized OAuth2 client.
     ![Client ID and secret of a new OAuth2 application](../_images/user/oauth2-provider/authsource-provider-show.png)
-- On https://v7.next.forgejo.org, login as a user with admin privileges
+- On https://v7.next.forgejo.org, log in as a user with admin privileges.
   - Create a new authentication source on https://v7.next.forgejo.org, the Forgejo instance that is going to act as the OAuth2 client, allowing its users to register using the account they have on https://codeberg.org.
     - Visit https://v7.next.forgejo.org/admin/auths/new to create the authentication source with:
       - **Authentication type:** OAuth2
-      - **Authentication name:** the arbitrary name that was chosen above (e.g. **Codeberg**)
+      - **Authentication name:** the arbitrary name that was chosen above (e.g., **Codeberg**)
       - **OAuth2 provider:** OpenID Connect
-      - **Client ID:** copy/pasted from the OAuth2 application created on Codebeg
-      - **Client Secret:** copy/pasted from the OAuth2 application created on Codebeg
+      - **Client ID:** copy/pasted from the OAuth2 application created on Codeberg
+      - **Client Secret:** copy/pasted from the OAuth2 application created on Codeberg
       - **Icon URL:** https://design.codeberg.org/logo-kit/icon.svg
       - **OpenID Connect Auto Discovery URL:** https://codeberg.org/.well-known/openid-configuration
-      - Leave all other fields to their default values
+      - Leave all other fields at their default values.
         ![Create a new OAuth2 authentication source](../_images/user/oauth2-provider/authsource-client-create.png)
     - It will show in the list of authentication sources at https://v7.next.forgejo.org/admin/auths.
       ![List of OAuth2 authentication source](../_images/user/oauth2-provider/authsource-client-list.png)
-- On https://v7.next.forgejo.org, not logged in
-  - Visit https://v7.next.forgejo.org/user/login
+- On https://v7.next.forgejo.org, not logged in.
+  - Visit https://v7.next.forgejo.org/user/login.
     ![Login page with Codeberg authentication source](../_images/user/oauth2-provider/authsource-intro-login-page.png)
-  - Click on **Sign in with Codeberg** to be redirected to Codeberg and authorize https://v7.next.forgejo.org to obtain the details of your account (user name, email, etc.). If you are not already logged in Codeberg, you will need to before this authorization request is presented to you.
+  - Click on **Sign in with Codeberg** to be redirected to Codeberg and authorize https://v7.next.forgejo.org to obtain the details of your account (user name, email, etc.). If you are not already logged in to Codeberg, you will need to before this authorization request is presented to you.
     ![Authorizing v7.next.forgejo.org](../_images/user/oauth2-provider/authsource-intro-login-confirm.png)
   - Review the pre-filled information that will be used to create your account on https://v7.next.forgejo.org.
     ![Filling account information](../_images/user/oauth2-provider/authsource-intro-login-create.png)
@@ -170,16 +170,16 @@ In this example https://v7.next.forgejo.org will be configured to add the option
 
 PKCE (Proof Key for Code Exchange) is an extension to the OAuth flow which allows for a secure credential exchange without the requirement to provide a client secret.
 
-**Note**: Please ensure you have registered your OAuth application as a public client.
+**Note:** Please ensure you have registered your OAuth application as a public client.
 
-To achieve this, you have to provide a `code_verifier` for every authorization request. A `code_verifier` has to be a random string with a minimum length of 43 characters and a maximum length of 128 characters. It can contain alphanumeric characters as well as the characters `-`, `.`, `_` and `~`.
+To achieve this, you have to provide a `code_verifier` for every authorization request. A `code_verifier` has to be a random string with a minimum length of 43 characters and a maximum length of 128 characters. It can contain alphanumeric characters as well as the characters `-`, `.`, `_`, and `~`.
 
 Using this `code_verifier` string, a new one called `code_challenge` is created by using one of two methods:
 
 - If you have the required functionality on your client, set `code_challenge` to be a URL-safe base64-encoded string of the SHA256 hash of `code_verifier`. In that case, your `code_challenge_method` becomes `S256`.
 - If you are unable to do so, you can provide your `code_verifier` as a plain string to `code_challenge`. Then you have to set your `code_challenge_method` as `plain`.
 
-After you have generated this values, you can continue with your request.
+After you have generated these values, you can continue with your request.
 
 1. Redirect the user to the authorization endpoint in order to get their consent for accessing the resources:
 

docs/user/packages/npm.md

@@ -95,7 +95,7 @@ npm install @test/test_package
 
 ## Tag a package
 
-The registry supports [version tags](https://docs.npmjs.com/adding-dist-tags-to-packages/) which can be managed by `npm dist-tag`:
+The registry supports [version tags](https://docs.npmjs.com/adding-dist-tags-to-packages/), which can be managed by `npm dist-tag`:
 
 ```shell
 npm dist-tag add {package_name}@{version} {tag}

docs/user/packages/vagrant.md

@@ -33,7 +33,7 @@ curl --user your_username:your_password_or_token \
      https://forgejo.example.com/api/packages/testuser/vagrant/test_system/1.0.0/hyperv.box
 ```
 
-If you are using 2FA or OAuth use a personal access token instead of the password.
+If you are using 2FA or OAuth, use a personal access token instead of the password.
 
 You cannot publish a box if a box of the same name, version and provider already exists. You must delete the existing package first.
 

docs/user/profile.md

@@ -4,7 +4,7 @@ license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/profile-readme.en-us.md'
 ---
 
-By default the profile page of a user (or an organization) is the list of repositories they
+By default, the profile page of a user (or an organization) is the list of repositories they
 own. It is possible to customize it with a short description that
 shows to the left, under their avatar. It can now be fully
 personalized with a markdown file that is displayed instead of the

docs/user/protection.md

@@ -7,7 +7,7 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
 ## Protected branches
 
 Protected branches enforce restrictions such as force pushing or
-merging unless a given number of approval are obtained on a pull
+merging unless a given number of approvals are obtained on a pull
 request.
 
 To protect a branch, you need to go to the repository’s **Settings** >
@@ -30,13 +30,13 @@ Protected tags allow control over who has permission to create or update Git tag
 To protect a tag, you need to follow these steps:
 
 1. Go to the repository’s **Settings** > **Tags** page.
-1. Type a pattern to match a name. You can use a single name, a [glob pattern](https://pkg.go.dev/github.com/gobwas/glob#Compile) or a regular expression.
-1. Choose the allowed users and/or teams. If you leave these fields empty no one is allowed to create or modify this tag.
-1. Select **Save** to save the configuration.
+2. Type a pattern to match a name. You can use a single name, a [glob pattern](https://pkg.go.dev/github.com/gobwas/glob#Compile) or a regular expression.
+3. Choose the allowed users and/or teams. If you leave these fields empty, no one is allowed to create or modify this tag.
+4. Select **Save** to save the configuration.
 
 ### Pattern protected tags
 
-The pattern uses [glob](https://pkg.go.dev/github.com/gobwas/glob#Compile) or regular expressions to match a tag name. For regular expressions you need to enclose the pattern in slashes.
+The pattern uses [glob](https://pkg.go.dev/github.com/gobwas/glob#Compile) or regular expressions to match a tag name. For regular expressions, you need to enclose the pattern in slashes.
 
 Examples:
 

docs/user/pull-requests-and-git-flow.md

@@ -6,20 +6,20 @@ origin_author: 'Codeberg Docs Contributors'
 origin_title: 'Pull requests and Git flow'
 ---
 
-## Benefits of a pull request based workflow
+## Benefits of a pull request-based workflow
 
 > **_TLDR:_** _Keep an eye on your repository and organization permissions. Don't take sweets from strangers. Use pull requests. Easy to review, easy to manage, and only the project maintainers/owners have permission to merge them._
 
-Although it is perfectly possible to use a Git project on Codeberg just as single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
+Although it is perfectly possible to use a Git project on Codeberg just as a single shared central repository for individuals and teams, a collaborative workflow based on pull requests provides many benefits:
 
 - The "hot" project repository requires only very few maintainers with full rights to sign off pull requests. Contributors can easily work on forked repositories.
 - Each pull request collects the full edit history for a fix or feature branch. Contributors can squash this, or keep it, just as they prefer.
 
 ## Create a pull request
 
-Let's say, you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/knut/examples).
+Let's say you would like to contribute to our "examples" project [knut/examples](https://codeberg.org/knut/examples).
 
-First, fork the project you would like to work on, by clicking the `Fork` button in the top-right corner of the project page:
+First, fork the project you would like to work on by clicking the `Fork` button in the top-right corner of the project page:
 
 ![Fork a project](../_images/user/pull-request/fork-button.png)
 
@@ -29,11 +29,11 @@ Then, clone it onto your local machine. We assume that [you have set up your SSH
 git clone git@codeberg.org:<YOURCODEBERGUSERNAME>/examples.git
 ```
 
-Now, let's create a feature branch, do some changes, commit, push, edit, commit, push, ..., edit, commit, push:
+Now, let's create a feature branch, make some changes, commit, push, edit, commit, push, ..., edit, commit, push:
 
 ```shell
 git checkout -b feature
-# do some changes
+# make some changes
 git commit -m "first feature"
 git push    # here you get asked to set your upstream URL, just confirm
 # do more work, edit...
@@ -51,9 +51,9 @@ Now you can create a pull request by visiting the main repository page and click
 
 This button is automatically shown if:
 
-- You are the pusher on a branch that still exists and that is not the default branch
-- The push must occurred within the last 6 hours
-- There is no open PR for this branch
+- You are the pusher on a branch that still exists and that is not the default branch.
+- The push must have occurred within the last 6 hours.
+- There is no open PR for this branch.
 
 ## Reviews
 
@@ -61,7 +61,7 @@ On the pull request page, the `Files Changed` tab shows a `Review` button that c
 
 ![Review a pull request](../_images/user/pull-request/pull-request-review-global.png)
 
-Next to each changed line, a `plus` button allows to add a comment on that specific line, for instance to suggest a modification.
+Next to each changed line, a `plus` button allows you to add a comment on that specific line, for instance, to suggest a modification.
 
 ![Review comment on a line](../_images/user/pull-request/pull-request-review-line.png)
 
@@ -103,32 +103,32 @@ docs/.* @MyOrg/editors
 
 Sometimes the upstream project repository is evolving while we are working on a feature branch, and we need to rebase and resolve merge conflicts for upstream changes into our feature branch. This is not hard:
 
-In order to track the `upstream` repository, we'll add a second remote that is pointing to the original project. This has to be done only once:
+In order to track the `upstream` repository, we'll add a second remote that points to the original project. This has to be done only once:
 
 ```shell
 git remote add upstream git@codeberg.org:knut/examples.git
 ```
 
-You can also use the SSH variant here for public projects, if you want to be
+You can also use the SSH variant here for public projects if you want to be
 able to pull without specifying your credentials.
 
-Now, let's pull from `upstream`, and rebase our local branch against the latest `HEAD` of the upstream project repository (e.g. the `main` branch):
+Now, let's pull from `upstream`, and rebase our local branch against the latest `HEAD` of the upstream project repository (e.g., the `main` branch):
 
 ```shell
 git pull --rebase upstream main
 git pull
 ```
 
-That's it. You can now push your changes, and create the pull request as usual by clicking on the "New Pull Request" button.
+That's it. You can now push your changes and create the pull request as usual by clicking on the "New Pull Request" button.
 
-## A friendly note on owner rights, and force push permissions
+## A friendly note on owner rights and force push permissions
 
 Please keep in mind that project owners can do _everything_, including editing and rewriting the history using `force-push`. In some cases, this is a useful feature
-(for example to undo accidental commits or clean up PRs),
-but in most cases a transparent history based on a pull request based workflow is surely preferable,
+(for example, to undo accidental commits or clean up PRs),
+but in most cases, a transparent history based on a pull request-based workflow is surely preferable,
 especially for the default branches of your project where other people rely on intact history.
 
 **Warning** If you accidentally leaked sensitive data, say, leaked credentials,
-keep in mind that commits stay directly accessible, e.g. from the user
+keep in mind that commits stay directly accessible, e.g., from the user
 activity tab or a Pull Request feed, for a while.
 Please contact us if you really need to remove such data from the public.

docs/user/push-to-create.md

@@ -6,15 +6,15 @@ origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8
 
 ## Push To Create
 
-Push to create is a feature that allows you to push to a repository that does not exist yet in Forgejo. This is useful for automation and for allowing users to create repositories without having to go through the web interface. This feature is disabled by default.
+Push to create is a feature that allows you to push to a repository that does not yet exist in Forgejo. This is useful for automation and for allowing users to create repositories without having to go through the web interface. This feature is disabled by default.
 
 ### Enabling Push To Create
 
-In the `app.ini` file, under the section `[repository]`, set `ENABLE_PUSH_CREATE_USER` to `true` and `ENABLE_PUSH_CREATE_ORG` to `true` if you want to allow users to create repositories in their own user account and in organizations they are a member of respectively. Restart Forgejo for the changes to take effect. You can read more about these two options in the Configuration Cheat Sheet.
+In the `app.ini` file, under the section `[repository]`, set `ENABLE_PUSH_CREATE_USER` to `true` and `ENABLE_PUSH_CREATE_ORG` to `true` if you want to allow users to create repositories in their own user account and in organizations they are members of, respectively. Restart Forgejo for the changes to take effect. You can read more about these two options in the Configuration Cheat Sheet.
 
 ### Using Push To Create
 
-Assuming you have a git repository in the current directory, you can push to a repository that does not exist yet in Forgejo by running the following command:
+Assuming you have a git repository in the current directory, you can push to a repository that does not yet exist in Forgejo by running the following command:
 
 ```shell
 # Add the remote you want to push to
@@ -28,7 +28,7 @@ This assumes you are using an SSH remote, but you can also use HTTPS remotes as
 
 ### Push options
 
-Push-to-create will default to the visibility defined by `DEFAULT_PUSH_CREATE_PRIVATE` in `app.ini`. To explicitly set the visibility there is support for some [push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt).
+Push-to-create will default to the visibility defined by `DEFAULT_PUSH_CREATE_PRIVATE` in `app.ini`. To explicitly set the visibility, there is support for some [push options](https://git-scm.com/docs/git-push#Documentation/git-push.txt--oltoptiongt).
 
 - `repo.private` (true|false) - Change the repository's visibility.
 

docs/user/readme-badges.md

@@ -5,7 +5,7 @@ license: 'CC-BY-SA-4.0'
 
 If the [badges service](../../admin/config-cheat-sheet/#badges-badges) is enabled, Forgejo makes it possible to add badges - transparently generated by a service like `shields.io` - to your READMEs and other documentation. These badges let you display useful information about your repository within documentation that might also be displayed elsewhere, outside of the forge itself (such as on container information pages, library documentation sites, and so on). Information such as the latest release, stars, pull request and issue information, or [Actions workflow](../actions/) statuses.
 
-The badges are returned in SVG format, and are available under the `https://forgejo.example.com/{username}/{repository}/badges` path. Forgejo currently supports generating the following badges:
+The badges are returned in SVG format and are available under the `https://forgejo.example.com/{username}/{repository}/badges` path. Forgejo currently supports generating the following badges:
 
 - `/release.svg`: The latest release made in the repository.
 - `/stars.svg`: The number of stars the repository has.
@@ -17,4 +17,4 @@ The badges are returned in SVG format, and are available under the `https://forg
 - `/pulls/closed.svg`: The number of closed pull requests.
 - `/workflows/{workflow_file}/badge.svg`: The status of the `{workflow_file}` workflow. Additional restrictions can be given for this badge by using the `branch` and/or `event` query parameters. The `branch` query parameter will display the status of the workflow from the given branch (defaulting to the repository's main branch if not explicitly specified), while the `event` parameter will only display results if a run was triggered by the specified event.
 
-All query parameters not known to Forgejo will be passed along to the badge generator service as-is. If using the default - `shields.io`-based - generator, this means that query parameters such as `style` and `color` will be respected.
+All query parameters not known to Forgejo will be passed along to the badge generator service as is. If using the default - `shields.io`-based - generator, this means that query parameters such as `style` and `color` will be respected.

docs/user/releases.md

@@ -9,31 +9,31 @@ origin_title: 'Tags and Releases'
 ## What are tags?
 
 Tags are a feature in Git that can be used to make a snapshot of a repository
-from a point in time. It is generally used to mark releases (e.g. v1.2.4), and
-it functions as a shortcut to see what the repo looked like at the time.
+from a point in time. It is generally used to mark releases (e.g., v1.2.4), and
+it functions as a shortcut to see what the repo looked like at that time.
 
 ## What are releases?
 
-Releases are a feature in Forgejo, independent of Git that allows you to attach
+Releases are a feature in Forgejo, independent of Git, that allows you to attach
 files and release notes along with the source code at the time, and share it in
 Forgejo, linking to a Git tag.
 
 ### Wait, what is the difference between tags and releases?
 
-They are very similar, the difference being that tags are just the repository
+They are very similar. The difference is that tags are just the repository
 frozen in time and are part of Git (you can make a tag inside of Git), but
-releases are tags accompanied with a binary file and are not part of Git (you
+releases are tags accompanied by a binary file and are not part of Git (you
 need to go to your repository page in the web interface to create a release).
 
 ## Creating tags and releases
 
 If you only want to create tags, using Git is recommended. If you want to create
 a full release, this is only possible through Forgejo's web interface, or
-through it's API.
+through its API.
 
 ### Creating a Tag with Git
 
-To create a tag using Git, use the following command in your local repository.
+To create a tag using Git, use the following command in your local repository:
 
 ```bash
 git tag -a <tag name> -m "<my tag message>"
@@ -42,8 +42,8 @@ git tag -a <tag name> -m "<my tag message>"
 You can omit `"<my tag message>"` to write a longer tag message in an editor
 window.
 
-**Tip:** Tags are generally labelled by version numbers. It is good practice to
-prefix a version number with a `v` (e.g. `v1.2.3`) and to use the [Semantic
+**Tip:** Tags are generally labeled by version numbers. It is good practice to
+prefix a version number with a `v` (e.g., `v1.2.3`) and to use the [Semantic
 Versioning](https://semver.org/) specification for assigning and incrementing
 version numbers.
 
@@ -77,7 +77,7 @@ the form of attaching files `(5)` or adding external links `(6)`:
 
 You can now either save it as a draft, or publish the release outright.
 
-You are then re-directed to the `Releases` tab of your repository. The newly
+You are then redirected to the `Releases` tab of your repository. The newly
 created release is now listed there:
 
 ![](../_images/user/releases/3.png)

docs/user/repo-mirror.md

@@ -10,8 +10,8 @@ Repository mirroring allows for the mirroring of repositories to and from extern
 
 The following are some possible use cases for repository mirroring:
 
-- You migrated to Forgejo but still need to keep your project in another source. In that case, you can simply set it up to mirror to Forgejo (pull) and all the essential history of commits, tags, and branches are available in your Forgejo instance.
-- You have old projects in another source that you don’t use actively anymore, but don’t want to remove for archiving purposes. In that case, you can create a push mirror so that your active Forgejo repository can push its changes to the old location.
+- You migrated to Forgejo but still need to keep your project in another source. In that case, you can simply set it up to mirror to Forgejo (pull), and all the essential history of commits, tags, and branches are available in your Forgejo instance.
+- You have old projects in another source that you don't use actively anymore but don't want to remove for archiving purposes. In that case, you can create a push mirror so that your active Forgejo repository can push its changes to the old location.
 
 ## Pulling from a remote repository
 
@@ -20,7 +20,7 @@ For an existing remote repository, you can set up pull mirroring as follows:
 1. Select **New Migration** in the **Create...** menu on the top right.
 2. Select the remote repository service.
 3. Enter a repository URL.
-4. If the repository needs authentication fill in your authentication information.
+4. If the repository needs authentication, fill in your authentication information.
 5. Check the box **This repository will be a mirror**.
 6. Select **Migrate repository** to save the configuration.
 
@@ -34,10 +34,10 @@ For an existing repository, you can set up push mirroring as follows:
 
 1. In your repository, go to **Settings** > **Repository**, and then the **Mirror Settings** section.
 2. Enter a repository URL.
-3. If the repository needs authentication expand the **Authorization** section and fill in your authentication information. Note that the requested **password** can also be your access token.
+3. If the repository needs authentication, expand the **Authorization** section and fill in your authentication information. Note that the requested **password** can also be your access token.
 4. Select **Add Push Mirror** to save the configuration.
 
-The repository now gets mirrored periodically to the remote repository. You can force a sync by selecting **Synchronize Now**. In case of an error a message displayed to help you resolve it.
+The repository now gets mirrored periodically to the remote repository. You can force a sync by selecting **Synchronize Now**. In case of an error, a message is displayed to help you resolve it.
 
 :exclamation::exclamation: **NOTE:** This will force push to the remote repository. This will overwrite any changes in the remote repository! :exclamation::exclamation:
 
@@ -49,7 +49,7 @@ To set up a mirror from Forgejo to GitHub, you need to follow these steps:
 2. Create a repository with that name on GitHub. Unlike Forgejo, GitHub does not support creating repositories by pushing to the remote. You can also use an existing remote repo if it has the same commit history as your Forgejo repo.
 3. In the settings of your Forgejo repo, fill in the **Git Remote Repository URL**: `https://github.com/<your_github_group>/<your_github_project>.git`.
 4. Fill in the **Authorization** fields with your GitHub username and the personal access token as **Password**.
-5. (Optional, available on Forgejo 1.18+) Select `Sync when new commits are pushed` so that the mirror will be updated as well as soon as there are changes. You can also disable the periodic sync if you like.
+5. (Optional, available on Forgejo 1.18+) Select `Sync when new commits are pushed` so that the mirror will be updated as soon as there are changes. You can also disable the periodic sync if you like.
 6. Select **Add Push Mirror** to save the configuration.
 
 The repository pushes shortly thereafter. To force a push, select the **Synchronize Now** button.
@@ -79,11 +79,11 @@ The repository pushes shortly thereafter. To force a push, select the **Synchron
 ### Mirror via SSH
 
 Forgejo supports the use of SSH as an authentication method for push mirrors.
-You can enable this when adding a new push mirror, existing push mirrors cannot be configured to use SSH.
+You can enable this when adding a new push mirror; existing push mirrors cannot be configured to use SSH.
 This feature is only available if Forgejo is able to find the `ssh` executable.
 
-To use SSH as authentication method, select the **Use SSH authentication** option in the authorization tab when adding a new push mirror.
-Make sure to use ssh conform URLs for **Git Remote Repository URL**, which is e.g. `git@forgejo.org:<your_forgejo_group>/<your_forgejo_project>.git` for Forgejo (differs to the default authorization approach as mentioned above).
+To use SSH as an authentication method, select the **Use SSH authentication** option in the authorization tab when adding a new push mirror.
+Make sure to use SSH-conform URLs for **Git Remote Repository URL**, which is e.g. `git@forgejo.org:<your_forgejo_group>/<your_forgejo_project>.git` for Forgejo (differs from the default authorization approach as mentioned above).
 Make sure to not fill in the **Username** or **Password** input.
 Forgejo generates an Ed25519 SSH key pair and saves it for you.
 
@@ -93,5 +93,5 @@ After adding the push mirror, you can click the **Copy public key** link to copy
 
 ![The push mirror entry is shown](../_images/user/repo-mirror/push_mirror_with_ssh.png)
 
-This public key can then be added as a deploy key on the target repository, how to add one varies by platform but generally it should be an option in the repository's settings.
+This public key can then be added as a deploy key on the target repository. How to add one varies by platform, but generally it should be an option in the repository's settings.
 After adding the public key as the deploy key, you can go back to Forgejo and click the **Synchronize now** button and see that it works.

docs/user/repo-permissions.md

@@ -14,7 +14,7 @@ You can assign teams different levels of permission for each unit (e.g. issues,
 
 The visibility of your repositories will depend on the visibility of your profile, as well as whether you have marked a repository as private. Let's break down what this means:
 
-- If your profile's visibility is set to "Limited", _all_ of your non-private repositories will only be visible to logged in users.
+- If your profile's visibility is set to "Limited", _all_ of your non-private repositories will only be visible to logged-in users.
 - If your profile's visibility is set to "Public", _all_ of your non-private repositories will be shown to everyone.
 - If you do not want anyone (apart from your fellow collaborators) to see your repositories, mark your repository as "Private".
 
@@ -24,7 +24,7 @@ The visibility of your profile can be changed in the `Privacy settings`. Be care
 
 ## Collaborators
 
-There are four permission levels: **Read**, **Write**, **Administrator** and **Owner**.
+There are four permission levels: **Read**, **Write**, **Administrator**, and **Owner**.
 
 By default, the person who creates a repository is an **_Owner_**.
 
@@ -32,7 +32,7 @@ The table below gives an overview of what collaborators are allowed to do when g
 
 | Task                                                                                                                     | Read | Write | Admin | Owner |
 | ------------------------------------------------------------------------------------------------------------------------ | ---- | ----- | ----- | ----- |
-| View, clone and pull repository                                                                                          | ✅   | ✅    | ✅    | ✅    |
+| View, clone, and pull repository                                                                                         | ✅   | ✅    | ✅    | ✅    |
 | Contribute pull requests                                                                                                 | ✅   | ✅    | ✅    | ✅    |
 | Push to/update contributed pull requests                                                                                 | ✅   | ✅    | ✅    | ✅    |
 | Push directly to repository                                                                                              | ❌   | ✅    | ✅    | ✅    |
@@ -51,16 +51,16 @@ The permissions for teams are quite configurable. You can specify which reposito
 Each unit is configured to have one of these 3 permission levels:
 
 - No Access: Members cannot view or take any other action on this unit.
-- Read: Members can view the unit, and do standard actions for that unit (See the Read column under [Collaborators](#collaborators)).
-- Write: Members can view the unit, and execute write actions that unit (See the Write column under [Collaborators](#collaborators)).
+- Read: Members can view the unit and perform standard actions for that unit (See the Read column under [Collaborators](#collaborators)).
+- Write: Members can view the unit and execute write actions for that unit (See the Write column under [Collaborators](#collaborators)).
 
-When a team is configured to have administrator access, when this is specified, you cannot change units. The team will have admin permissions (See the Admin column under _Collaborators_).
+When a team is configured to have administrator access, this is specified, and you cannot change units. The team will have admin permissions (See the Admin column under _Collaborators_).
 
 Currently, there are six units that can be configured:
 
 - Code: access source code, files, commits, and branches.
 - Issues: organize bug reports, tasks, and milestones.
-- Pull Requests: access pull requests, and code reviews.
+- Pull Requests: access pull requests and code reviews.
 - Releases: track the project versions and downloads.
 - Wiki: access and write documentation.
 - Projects: access and manage issues and pull requests in project boards.
@@ -70,4 +70,4 @@ There are also two units which can be toggled:
 - External Wiki: access to external wiki.
 - External Issues: access to the external issue tracker.
 
-A team can be given the permission to create new repositories. When a member of such team creates a new repository, they will get administrator access to the repository.
+A team can be given the permission to create new repositories. When a member of such a team creates a new repository, they will get administrator access to the repository.

docs/user/repository-activity.md

@@ -3,19 +3,19 @@ title: Repository Activity
 license: 'CC-BY-SA-4.0'
 ---
 
-For each repository, the activity tab displays insights about the recent changes. It helps figure out how lively it is and which contributors are the most active at a given moment in time.
+For each repository, the Activity tab displays insights about the recent changes. It helps figure out how lively it is and which contributors are the most active at a given moment in time.
 
 ## Contributors
 
 ![screenshot showing the contributors graph](../_images/user/repository-activity/contributors.png)
 
-The overall graph shows all commits over time and allows to select a range of dates to get a more detailed view. The contributors are also displayed with their individual graph. The contributor with the most commits is shown first.
+The overall graph shows all commits over time and allows you to select a range of dates to get a more detailed view. The contributors are also displayed with their individual graphs. The contributor with the most commits is shown first.
 
 ## Pulse
 
 ![screenshot showing the pulse graph](../_images/user/repository-activity/pulse.png)
 
-A high level view of of the most recent commits and pull requests.
+A high-level view of the most recent commits and pull requests.
 
 ## Code frequency
 

docs/user/token-scope.md

@@ -1,43 +1,43 @@
 ---
-title: 'Access Token scope'
+title: 'Access Token Scope'
 license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/development/oauth2-provider.en-us.md'
 ---
 
-Forgejo supports scoped access tokens, which allow users to restrict tokens to operate only on selected url routes. Scopes are grouped by high-level API routes, and further refined to the following:
+Forgejo supports scoped access tokens, which allow users to restrict tokens to operate only on selected URL routes. Scopes are grouped by high-level API routes, and further refined as follows:
 
 - `read`: `GET` routes
 - `write`: `POST`, `PUT`, `PATCH`, and `DELETE` routes (in addition to `GET`)
 
 Forgejo token scopes are as follows:
 
-| Name                                      | Description                                                                                                                                          |
-| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
-| **(no scope)**                            | Not supported. A scope is required even for public repositories.                                                                                     |
-| **activitypub**                           | `activitypub` API routes: ActivityPub related operations.                                                                                            |
-|     **read:activitypub**   | Grants read access for ActivityPub operations.                                                                                                       |
-|     **write:activitypub**  | Grants read/write/delete access for ActivityPub operations.                                                                                          |
-| **admin**                                 | `/admin/*` API routes: Site-wide administrative operations (hidden for non-admin accounts).                                                          |
-|     **read:admin**         | Grants read access for admin operations, such as getting cron jobs or registered user emails.                                                        |
-|     **write:admin**        | Grants read/write/delete access for admin operations, such as running cron jobs or updating user accounts.                                           |
-| **issue**                                 | `issues/*`, `labels/*`, `milestones/*` API routes: Issue-related operations.                                                                         |
-|     **read:issue**         | Grants read access for issues operations, such as getting issue comments, issue attachments, and milestones.                                         |
-|     **write:issue**        | Grants read/write/delete access for issues operations, such as posting or editing an issue comment or attachment, and updating milestones.           |
-| **misc**                                  | miscellaneous and settings top-level API routes.                                                                                                     |
-|     **read:misc**          | Grants read access to miscellaneous operations, such as getting label and gitignore templates.                                                       |
-|     **write:misc**         | Grants read/write/delete access to miscellaneous operations, such as markup utility operations.                                                      |
-| **notification**                          | `notification/*` API routes: user notification operations.                                                                                           |
-|     **read:notification**  | Grants read access to user notifications, such as which notifications users are subscribed to and read new notifications.                            |
-|     **write:notification** | Grants read/write/delete access to user notifications, such as marking notifications as read.                                                        |
-| **organization**                          | `orgs/*` and `teams/*` API routes: Organization and team management operations.                                                                      |
-|     **read:organization**  | Grants read access to org and team status, such as listing all organizations a user has visibility to, teams, and team members.                      |
-|     **write:organization** | Grants read/write/delete access to org and team status, such as creating and updating teams and updating org settings.                               |
-| **package**                               | `/packages/*` API routes: Packages operations                                                                                                        |
-|     **read:package**       | Grants read access to package operations, such as reading and downloading available packages.                                                        |
-|     **write:package**      | Grants read/write/delete access to package operations. Currently the same as `read:package`.                                                         |
-| **repository**                            | `/repos/*` API routes except `/repos/issues/*`: Repository file, pull-request, and release operations.                                               |
-|     **read:repository**    | Grants read access to repository operations, such as getting repository files, releases, collaborators.                                              |
-|     **write:repository**   | Grants read/write/delete access to repository operations, such as getting updating repository files, creating pull requests, updating collaborators. |
-| **user**                                  | `/user/*` and `/users/*` API routes: User-related operations.                                                                                        |
-|     **read:user**          | Grants read access to user operations, such as getting user repository subscriptions and user settings.                                              |
-|     **write:user**         | Grants read/write/delete access to user operations, such as updating user repository subscriptions, followed users, and user settings.               |
+| Name                                      | Description                                                                                                                                                  |
+| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **(no scope)**                            | Not supported. A scope is required even for public repositories.                                                                                             |
+| **activitypub**                           | `activitypub` API routes: ActivityPub related operations.                                                                                                    |
+|     **read:activitypub**   | Grants read access for ActivityPub operations.                                                                                                               |
+|     **write:activitypub**  | Grants read/write/delete access for ActivityPub operations.                                                                                                  |
+| **admin**                                 | `/admin/*` API routes: Site-wide administrative operations (hidden for non-admin accounts).                                                                  |
+|     **read:admin**         | Grants read access for admin operations, such as getting cron jobs or registered user emails.                                                                |
+|     **write:admin**        | Grants read/write/delete access for admin operations, such as running cron jobs or updating user accounts.                                                   |
+| **issue**                                 | `issues/*`, `labels/*`, `milestones/*` API routes: Issue-related operations.                                                                                 |
+|     **read:issue**         | Grants read access for issue operations, such as getting issue comments, issue attachments, and milestones.                                                  |
+|     **write:issue**        | Grants read/write/delete access for issue operations, such as posting or editing an issue comment or attachment, and updating milestones.                    |
+| **misc**                                  | Miscellaneous and settings top-level API routes.                                                                                                             |
+|     **read:misc**          | Grants read access to miscellaneous operations, such as getting label and gitignore templates.                                                               |
+|     **write:misc**         | Grants read/write/delete access to miscellaneous operations, such as markup utility operations.                                                              |
+| **notification**                          | `notification/*` API routes: User notification operations.                                                                                                   |
+|     **read:notification**  | Grants read access to user notifications, such as which notifications users are subscribed to and reading new notifications.                                 |
+|     **write:notification** | Grants read/write/delete access to user notifications, such as marking notifications as read.                                                                |
+| **organization**                          | `orgs/*` and `teams/*` API routes: Organization and team management operations.                                                                              |
+|     **read:organization**  | Grants read access to org and team status, such as listing all organizations a user has visibility to, teams, and team members.                              |
+|     **write:organization** | Grants read/write/delete access to org and team status, such as creating and updating teams and updating org settings.                                       |
+| **package**                               | `/packages/*` API routes: Packages operations.                                                                                                               |
+|     **read:package**       | Grants read access to package operations, such as reading and downloading available packages.                                                                |
+|     **write:package**      | Grants read/write/delete access to package operations. Currently the same as `read:package`.                                                                 |
+| **repository**                            | `/repos/*` API routes except `/repos/issues/*`: Repository file, pull-request, and release operations.                                                       |
+|     **read:repository**    | Grants read access to repository operations, such as getting repository files, releases, and collaborators.                                                  |
+|     **write:repository**   | Grants read/write/delete access to repository operations, such as getting and updating repository files, creating pull requests, and updating collaborators. |
+| **user**                                  | `/user/*` and `/users/*` API routes: User-related operations.                                                                                                |
+|     **read:user**          | Grants read access to user operations, such as getting user repository subscriptions and user settings.                                                      |
+|     **write:user**         | Grants read/write/delete access to user operations, such as updating user repository subscriptions, followed users, and user settings.                       |

docs/user/versions.md

@@ -3,16 +3,16 @@ title: Forgejo numbering scheme
 license: 'CC-BY-SA-4.0'
 ---
 
-The Forgejo versions looks like `X.Y.Z+gitea-A.B.C`
-(e.g. 7.0.0+gitea-1.22.0). The Forgejo version is the first part,
-before the '+' (e.g. 7.0.0) and the following metadata, after the '+'
+The Forgejo versions look like `X.Y.Z+gitea-A.B.C`
+(e.g., 7.0.0+gitea-1.22.0). The Forgejo version is the first part,
+before the '+' (e.g., 7.0.0), and the following metadata, after the '+',
 shows the Gitea version with which the API is compatible
-(e.g. 1.22.0).
+(e.g., 1.22.0).
 
 ## Obtaining the Forgejo version
 
 The Forgejo version is displayed in the footer of the web UI, in the
-output of the `forgejo --version` CLI and returned by two API
+output of the `forgejo --version` CLI, and returned by two API
 endpoints:
 
 - [example.com/api/v1/version](https://code.forgejo.org/api/swagger/#/miscellaneous/getVersion)
@@ -23,7 +23,7 @@ and they match what is displayed by the CLI or the web UI.
 
 ## Compatibility with Gitea
 
-As of Forgejo 7.0.0 tools designed to work with Gitea 1.22.0 and
+As of Forgejo 7.0.0, tools designed to work with Gitea 1.22.0 and
 below are compatible and do not need any modification to keep working.
 
 In the future, if a tool wants to assert the level of compatibility of
@@ -32,10 +32,10 @@ a Forgejo version with Gitea, it can:
 - Obtain the version number [example.com/api/v1/version](https://code.forgejo.org/api/swagger/#/miscellaneous/getVersion) using the same API endpoint as Gitea
 - If the returned version contains '+gitea-', keep what follows as the compatible Gitea version number
 
-For instance Gitnex will not notice a difference when the version
+For instance, Gitnex will not notice a difference when the version
 number is bumped from Forgejo 1.21.7-0 to Forgejo 7.0.0. It only uses
 version numbers to verify if a new feature is available in a newer
-version. The last time such a check was added was with Gitea 1.17
+version. The last time such a check was added was with Gitea 1.17,
 which was published in July 2022.
 
 ## Semantic Version
@@ -48,11 +48,11 @@ which was published in July 2022.
 
 Forgejo changes reflected in the version could be:
 
-- a command, an option or an argument, for a CLI
-- a route path, a query parameter or a body property, for a REST API
-- a text node, a button or a field, for a GUI
+- a command, an option, or an argument, for a CLI
+- a route path, a query parameter, or a body property, for a REST API
+- a text node, a button, or a field, for a GUI
 
-Since Forgejo has all of the above, changes to all of those components are be taken into consideration when creating a new version number.
+Since Forgejo has all of the above, changes to all of those components are taken into consideration when creating a new version number.
 
 ### Stable versions
 
@@ -71,13 +71,13 @@ The structure of the version number is `<MAJOR>.<MINOR>.<PATCH>-dev-<SHA>+gitea-
 
 ## Legacy forgejo numbering scheme
 
-In Forgejo versions prior to 7.0.0, i.e. from 1.18.0-1 to 1.21.7-0
+In Forgejo versions prior to 7.0.0, i.e., from 1.18.0-1 to 1.21.7-0
 included, the Forgejo version matched the Gitea version by removing
 the string following the trailing dash (-) and the release cycles were
 synchronized.
 
 The version number A.B.C-N was displayed with the dash (-) replaced by a plus
-(+) (e.g. Forgejo 1.18.0-1 was displayed as 1.18.0+1). The two API
+(+) (e.g., Forgejo 1.18.0-1 was displayed as 1.18.0+1). The two API
 endpoints returned different results:
 
 - [example.com/api/v1/version](https://code.forgejo.org/api/swagger/#/miscellaneous/getVersion) returned `{"version":"A.B.C+N"}`

docs/user/webhooks.md

@@ -4,8 +4,8 @@ license: 'Apache-2.0'
 origin_url: 'https://github.com/go-gitea/gitea/blob/e865de1e9d65dc09797d165a51c8e705d2a86030/docs/content/usage/webhooks.en-us.md'
 ---
 
-Forgejo supports webhooks for repository events. This can be configured in the settings
-page `/:username/:reponame/settings/hooks` by a repository admin. Webhooks can also be configured on a per-organization and whole system basis (default webhooks on repository creation or instance-wide webhooks).
+Forgejo supports webhooks for repository events. This can be configured on the settings
+page `/:username/:reponame/settings/hooks` by a repository admin. Webhooks can also be configured on a per-organization and whole-system basis (default webhooks on repository creation or instance-wide webhooks).
 The currently supported webhook types are:
 
 ### Raw event as JSON or FORM payload:
@@ -16,7 +16,7 @@ The currently supported webhook types are:
 
 ### Dedicated integration:
 
-- Packagist: ask packagist to refresh the given package
+- Packagist: ask Packagist to refresh the given package
 - SourceHut Builds: submit build manifests (only on push)
 
 ### Generic notification messages in chosen channel/chat:
@@ -120,7 +120,7 @@ X-Gitea-Event: push
 ### Example
 
 This is an example of how to use webhooks to run a PHP script upon push requests to the repository.
-In your repository Settings, under Webhooks, Setup a Forgejo webhook as follows:
+In your repository Settings, under Webhooks, set up a Forgejo webhook as follows:
 
 - Target URL: http://example.com/webhook.php
 - HTTP Method: POST
@@ -129,7 +129,7 @@ In your repository Settings, under Webhooks, Setup a Forgejo webhook as follows:
 - Trigger On: Push Events
 - Active: Checked
 
-Now on your server create the PHP file webhook.php
+Now, on your server, create the PHP file `webhook.php`.
 
 ```
 <?php
@@ -187,7 +187,7 @@ if (json_last_error() !== JSON_ERROR_NONE) {
 // success, do something
 ```
 
-There is a Test Delivery button in the webhook settings that allows to test the configuration as well as a list of the most Recent Deliveries.
+There is a Test Delivery button in the webhook settings that allows testing the configuration as well as a list of the most Recent Deliveries.
 
 ### Authorization header
 

docs/user/wiki.md

@@ -6,33 +6,33 @@ origin_author: 'Codeberg Docs Contributors'
 origin_title: 'Integrated Wiki'
 ---
 
-A [wiki](https://en.wikipedia.org/wiki/Wiki) is a collaborative space on the web. It is a common practice to use wikis to collect knowledge and share information.  
+A [wiki](https://en.wikipedia.org/wiki/Wiki) is a collaborative space on the web. It is a common practice to use wikis to collect knowledge and share information.
 Codeberg allows you to add a wiki to a repository for additional documentation.
 
-The user in these examples is `knut`, the polar bear and its repository is `foobar`.
+The user in these examples is `knut`, the polar bear, and its repository is `foobar`.
 
 ## Activation and Permissions
 
-To enable the wiki for a repository, visit the `Settings` page and activate `Enable Repository Wiki` in the `Advanced Section`. It will default to the built-in wiki which is described here, but you can add an URI to an external site the "Wiki" tab should link to.
+To enable the wiki for a repository, visit the `Settings` page and activate `Enable Repository Wiki` in the `Advanced Section`. It will default to the built-in wiki which is described here, but you can add a URI to an external site the "Wiki" tab should link to.
 
-> **Warning**  
-> Be aware that the wiki, once enabled, is accessible for _everyone_ who has `read` access to your repository - on public repositories even unauthenticated guests can access the wiki.  
+> **Warning**
+> Be aware that the wiki, once enabled, is accessible to _everyone_ who has `read` access to your repository - on public repositories even unauthenticated guests can access the wiki.
 > The wiki is _not_ a suitable place for storing private information or secrets (like passwords).
 >
 > Activating the `Allow anyone to edit the Wiki` option in `Settings` will give everyone with an account write access to the wiki.
 
-To edit the wiki `write` permission to the repository is required, unless the `Allow anyone to edit the Wiki` setting is activated on the `Settings` page, in the `Advanced Settings` section.
+To edit the wiki, `write` permission to the repository is required, unless the `Allow anyone to edit the Wiki` setting is activated on the `Settings` page, in the `Advanced Settings` section.
 
 ## Wiki structure
 
 The wiki is essentially a separate Git repository in your repository with a predefined name in the form of `<your-repository-name>.wiki.git`.
 
-It consists of [Markdown](https://en.wikipedia.org/wiki/Markdown) files (file extension `.md`) and additional assets like images.  
+It consists of [Markdown](https://en.wikipedia.org/wiki/Markdown) files (file extension `.md`) and additional assets like images.
 No further stylesheets are needed. The Markdown files are automatically rendered according to the selected Forgejo theme.
 
 ## Adding content via web
 
-After you have enabled the wiki you are prompted to create the initial page `Home.md`.
+After you have enabled the wiki, you are prompted to create the initial page `Home.md`.
 
 The web UI in your browser is currently limited to adding, updating, and deleting pages; you can't manage assets like images this way.
 
@@ -93,9 +93,9 @@ After saving your changes, the image should be visible.
 
 ## Adding a sidebar and a footer
 
-To enhance the usability of your wiki you can add a custom sidebar and a footer that are shown on every page. The sidebar will be displayed to the right of the main content and the footer below.
+To enhance the usability of your wiki, you can add a custom sidebar and a footer that are shown on every page. The sidebar will be displayed to the right of the main content and the footer below.
 
-To enable the sidebar, just add a file named `_Sidebar.md` to your wiki. For a footer the file must be named `_Footer.md`.
+To enable the sidebar, just add a file named `_Sidebar.md` to your wiki. For a footer, the file must be named `_Footer.md`.
 Both file types allow common Markdown syntax to adjust the presentation to your needs.
 
 Very basic example for a sidebar:
@@ -110,14 +110,14 @@ Very basic example for a sidebar:
 > knuts wiki
 ```
 
-> These files starting with `_` are hidden, so in the web UI you need to manually browse for the files. E.g. for our user _knut_ and his _foobar_ repo:  
+> These files starting with `_` are hidden, so in the web UI you need to manually browse for the files. E.g. for our user _knut_ and his _foobar_ repo:
 > `https://codeberg.org/knut/foobar/wiki/_Sidebar`
 
 ## Embedding LaTeX-style equations
 
 The wiki also supports embedding LaTeX-style equations in Markdown files, using [KaTeX](https://katex.org).
 
-Such equations go between two `$` characters, for example like this:
+Such equations go between two `$` characters, for example, like this:
 
 ```markdown
 $ \frac{1}{2} = 0.5 $