Fix various typos of software names (#18083)

* `git` -> `Git`
* `Github` and `github` -> `GitHub`
* `crowdin` -> `Crowdin`
* `git-lfs` -> `Git LFS`
* `githooks`, `git hooks`, `git-hooks` -> `Git Hooks`
* `discord` -> `Discord`
* `2fa` -> `2FA`
* `gitlab` and `Gitlab` -> `GitLab`
* `web hook` -> `webhook`
* `linux` -> `Linux`
* `sqlite` -> `SQLite`
* `MYSQL` and `mysql` -> `MySQL`
* rename refs to `master` branch -> `main`
* Fix English grammar

.github/pull_request_template.md

 Please check the following:
 
 1. Make sure you are targeting the `main` branch, pull requests on release branches are only allowed for bug fixes.
-2. Read contributing guidelines: https://github.com/go-gitea/gitea/blob/master/CONTRIBUTING.md
+2. Read contributing guidelines: https://github.com/go-gitea/gitea/blob/main/CONTRIBUTING.md
 3. Describe what your pull request does and which issue you're targeting (if any)
 
 -->  

CONTRIBUTING.md

 |``make lint-frontend`` | lint frontend files  |
 |``make lint-backend``  | lint backend files   |
 
-- run test code (Suggest run in linux)  
+- run test code (Suggest run in Linux)  
 
 |                                        |                                                  |
 | :------------------------------------- | :----------------------------------------------- |
 |``make test[\#TestSpecificName]``       |  run unit test  |
-|``make test-sqlite[\#TestSpecificName]``|  run [integration](integrations) test for sqlite |  
-|[More detail message about integrations](integrations/README.md)  |
+|``make test-sqlite[\#TestSpecificName]``|  run [integration](integrations) test for SQLite |  
+|[More details about integrations](integrations/README.md)  |
 
 ## Vendoring
 
 ## Translation
 
 We do all translation work inside [Crowdin](https://crowdin.com/project/gitea).
-The only translation that is maintained in this git repository is
+The only translation that is maintained in this Git repository is
 [`en_US.ini`](https://github.com/go-gitea/gitea/blob/master/options/locale/locale_en-US.ini)
 and is synced regularly to Crowdin. Once a translation has reached
 A SATISFACTORY PERCENTAGE it will be synced back into this repo and
 
 ## Design guideline
 
-To maintain understandable code and avoid circular dependencies it is important to have a good structure of the code. The gitea code is divided into the following parts:
+To maintain understandable code and avoid circular dependencies it is important to have a good structure of the code. The Gitea code is divided into the following parts:
 
 - **integration:** Integrations tests
 - **models:** Contains the data structures used by xorm to construct database tables. It also contains supporting functions to query and update the database. Dependencies to other code in Gitea should be avoided although some modules might be needed (for example for logging).
 Signed-off-by: Joe Smith <joe.smith@email.com>
 ```
 
-If you set your `user.name` and `user.email` git configs, you can add the
+If you set your `user.name` and `user.email` Git configs, you can add the
 line to the end of your commit automatically with `git commit -s`.
 
 We assume in good faith that the information you provide is legally binding.
 months and forgets to leave the maintainers team, the owners may move
 him or her from the maintainers team to the advisors team.
 For security reasons, Maintainers should use 2FA for their accounts and
-if possible provide gpg signed commits.
+if possible provide GPG signed commits.
 https://help.github.com/articles/securing-your-account-with-two-factor-authentication-2fa/
 https://help.github.com/articles/signing-commits-with-gpg/
 
 
 ## Versions
 
-Gitea has the `master` branch as a tip branch and has version branches
+Gitea has the `main` branch as a tip branch and has version branches
 such as `release/v0.9`. `release/v0.9` is a release branch and we will
 tag `v0.9.0` for binary download. If `v0.9.0` has bugs, we will accept
 pull requests on the `release/v0.9` branch and publish a `v0.9.1` tag,
-after bringing the bug fix also to the master branch.
+after bringing the bug fix also to the main branch.
 
-Since the `master` branch is a tip version, if you wish to use Gitea
+Since the `main` branch is a tip version, if you wish to use Gitea
 in production, please download the latest release tag version. All the
 branches will be protected via GitHub, all the PRs to every branch must
 be reviewed by two maintainers and must pass the automatic tests.
 ## Releasing Gitea
 
 * Let $vmaj, $vmin and $vpat be Major, Minor and Patch version numbers, $vpat should be rc1, rc2, 0, 1, ...... $vmaj.$vmin will be kept the same as milestones on github or gitea in future.
-* Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
-* If this is a big version first you have to create PR for changelog on branch `master` with PRs with label `changelog` and after it has been merged do following steps:
+* Before releasing, confirm all the version's milestone issues or PRs has been resolved. Then discuss the release on Discord channel #maintainers and get agreed with almost all the owners and mergers. Or you can declare the version and if nobody against in about serval hours.
+* If this is a big version first you have to create PR for changelog on branch `main` with PRs with label `changelog` and after it has been merged do following steps:
   * Create `-dev` tag as `git tag -s -F release.notes v$vmaj.$vmin.0-dev` and push the tag as `git push origin v$vmaj.$vmin.0-dev`.
   * When CI has finished building tag then you have to create a new branch named `release/v$vmaj.$vmin`
 * If it is bugfix version create PR for changelog on branch `release/v$vmaj.$vmin` and wait till it is reviewed and merged.
 * Add a tag as `git tag -s -F release.notes v$vmaj.$vmin.$`, release.notes file could be a temporary file to only include the changelog this version which you added to `CHANGELOG.md`.
-* And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically created a release and upload all the compiled binary. (But currently it didn't add the release notes automatically. Maybe we should fix that.)
-* If needed send PR for changelog on branch `master`.
+* And then push the tag as `git push origin v$vmaj.$vmin.$`. Drone CI will automatically create a release and upload all the compiled binary. (But currently it doesn't add the release notes automatically. Maybe we should fix that.)
+* If needed send PR for changelog on branch `main`.
 * Send PR to [blog repository](https://gitea.com/gitea/blog) announcing the release.
 
 ## Copyright

README.md

 
     TAGS="bindata" make build
 
-or if sqlite support is required:
+or if SQLite support is required:
 
     TAGS="bindata sqlite sqlite_unlock_notify" make build
 

docs/content/doc/advanced/adding-legal-pages.en-us.md

 Gitea source code ships with sample pages, available in `contrib/legal` directory. Copy them to `custom/public/`. For example, to add Privacy Policy:
 
 ```
-wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/master/contrib/legal/privacy.html.sample
+wget -O /path/to/custom/public/privacy.html https://raw.githubusercontent.com/go-gitea/gitea/main/contrib/legal/privacy.html.sample
 ```
 
 Now you need to edit the page to meet your requirements. In particular you must change the email addresses, web addresses and references to "Your Gitea Instance" to match your situation.

docs/content/doc/advanced/clone-filter.en-us.md

 
 See [GitHub blog post: Get up to speed with partial clone](https://github.blog/2020-12-21-get-up-to-speed-with-partial-clone-and-shallow-clone/)
 for common use cases of clone filters (blobless and treeless clones), and
-[Gitlab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
+[GitLab docs for partial clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html)
 for more advanced use cases (such as filter by file size and remove
 filters to turn partial clone into full clone).

docs/content/doc/advanced/cmd-embedded.en-us.md

 The `--custom` flag tells Gitea to extract the files directly into the `custom` directory.
 For this to work, the command needs to know the location of the `app.ini` configuration
 file (`--config`) and, depending of the configuration, be ran from the directory where
-gitea normally starts. See [Customizing Gitea]({{< relref "doc/advanced/customizing-gitea.en-us.md" >}}) for details.
+Gitea normally starts. See [Customizing Gitea]({{< relref "doc/advanced/customizing-gitea.en-us.md" >}}) for details.
 
 The `--overwrite` flag allows any existing files in the destination directory to be overwritten.
 

docs/content/doc/advanced/config-cheat-sheet.en-us.md

 - `PPROF_DATA_PATH`: **data/tmp/pprof**: `PPROF_DATA_PATH`, use an absolute path when you start Gitea as service
 - `LANDING_PAGE`: **home**: Landing page for unauthenticated users \[home, explore, organizations, login\].
 
-- `LFS_START_SERVER`: **false**: Enables git-lfs support.
+- `LFS_START_SERVER`: **false**: Enables Git LFS support.
 - `LFS_CONTENT_PATH`: **%(APP_DATA_PATH)/lfs**: Default LFS content path. (if it is on local storage.) **DEPRECATED** use settings in `[lfs]`.
 - `LFS_JWT_SECRET`: **\<empty\>**: LFS authentication secret, change this a unique string.
 - `LFS_HTTP_AUTH_EXPIRY`: **20m**: LFS authentication validity period in time.Duration, pushes taking longer than this may fail.
      - `require`: Enable TLS without any verifications.
      - `verify-ca`: Enable TLS with verification of the database server certificate against its root certificate.
      - `verify-full`: Enable TLS and verify the database server name matches the given certificate in either the `Common Name` or `Subject Alternative Name` fields.
-- `SQLITE_TIMEOUT`: **500**: Query timeout for sqlite3 only.
+- `SQLITE_TIMEOUT`: **500**: Query timeout for SQLite3 only.
 - `ITERATE_BUFFER_SIZE`: **50**: Internal buffer size for iterating.
 - `CHARSET`: **utf8mb4**: For MySQL only, either "utf8" or "utf8mb4". NOTICE: for "utf8mb4" you must use MySQL InnoDB > 5.6. Gitea is unable to check this.
 - `PATH`: **data/gitea.db**: For SQLite3 only, the database file path.
 - `REVERSE_PROXY_LIMIT`: **1**: Interpret X-Forwarded-For header or the X-Real-IP header and set this as the remote IP for the request.
    Number of trusted proxy count. Set to zero to not use these headers.
 - `REVERSE_PROXY_TRUSTED_PROXIES`: **127.0.0.0/8,::1/128**: List of IP addresses and networks separated by comma of trusted proxy servers. Use `*` to trust all.
-- `DISABLE_GIT_HOOKS`: **true**: Set to `false` to enable users with git hook privilege to create custom git hooks.
-   WARNING: Custom git hooks can be used to perform arbitrary code execution on the host operating system.
+- `DISABLE_GIT_HOOKS`: **true**: Set to `false` to enable users with Git Hook privilege to create custom Git Hooks.
+   WARNING: Custom Git Hooks can be used to perform arbitrary code execution on the host operating system.
    This enables the users to access and modify this config file and the Gitea database and interrupt the Gitea service.
    By modifying the Gitea database, users can gain Gitea administrator privileges.
    It also enables them to access other resources available to the user on the operating system that is running the
 - `DEFAULT_ORG_MEMBER_VISIBLE`: **false** True will make the membership of the users visible when added to the organisation.
 - `ALLOW_ONLY_INTERNAL_REGISTRATION`: **false** Set to true to force registration only via Gitea.
 - `ALLOW_ONLY_EXTERNAL_REGISTRATION`: **false** Set to true to force registration only using third-party services.
-- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
+- `NO_REPLY_ADDRESS`: **noreply.DOMAIN** Value for the domain part of the user's email address in the Git log if user has set KeepEmailPrivate to true. DOMAIN resolves to the value in server.DOMAIN.
   The user's email will be replaced with a concatenation of the user name in lower case, "@" and NO_REPLY_ADDRESS.
 - `USER_DELETE_WITH_COMMENTS_MAX_TIME`: **0** Minimum amount of time a user must exist before comments are kept when the user is deleted.
 - `VALID_SITE_URL_SCHEMES`: **http, https**: Valid site url schemes for user profiles
 - `MAILER_TYPE`: **smtp**: \[smtp, sendmail, dummy\]
    - **smtp** Use SMTP to send mail
    - **sendmail** Use the operating system's `sendmail` command instead of SMTP.
-   This is common on linux systems.
+   This is common on Linux systems.
    - **dummy** Send email messages to the log as a testing phase.
    - Note that enabling sendmail will ignore all other `mailer` settings except `ENABLED`,
      `FROM`, `SUBJECT_PREFIX` and `SENDMAIL_PATH`.
 
 ## Git (`git`)
 
-- `PATH`: **""**: The path of git executable. If empty, Gitea searches through the PATH environment.
+- `PATH`: **""**: The path of Git executable. If empty, Gitea searches through the PATH environment.
 - `DISABLE_DIFF_HIGHLIGHT`: **false**: Disables highlight of added and removed changes.
 - `MAX_GIT_DIFF_LINES`: **1000**: Max number of lines allowed of a single file in diff view.
 - `MAX_GIT_DIFF_LINE_CHARACTERS`: **5000**: Max character count per line highlighted in diff view.
 - `COMMITS_RANGE_SIZE`: **50**: Set the default commits range size
 - `BRANCHES_RANGE_SIZE`: **20**: Set the default branches range size
 - `GC_ARGS`: **\<empty\>**: Arguments for command `git gc`, e.g. `--aggressive --auto`. See more on http://git-scm.com/docs/git-gc/
-- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use git wire protocol version 2 when git version >= 2.18, default is true, set to false when you always want git wire protocol version 1
+- `ENABLE_AUTO_GIT_WIRE_PROTOCOL`: **true**: If use Git wire protocol version 2 when Git version >= 2.18, default is true, set to false when you always want Git wire protocol version 1
 - `PULL_REQUEST_PUSH_MESSAGE`: **true**: Respond to pushes to a non-default branch with a URL for creating a Pull Request (if the repository has them enabled)
 - `VERBOSE_PUSH`: **true**: Print status information about pushes as they are being processed.
 - `VERBOSE_PUSH_DELAY`: **5s**: Only print verbose information if push takes longer than this delay.
 - `ENABLE_SWAGGER`: **true**: Enables /api/swagger, /api/v1/swagger etc. endpoints. True or false; default is true.
 - `MAX_RESPONSE_ITEMS`: **50**: Max number of items in a page.
 - `DEFAULT_PAGING_NUM`: **30**: Default paging number of API.
-- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: Default and maximum number of items per page for git trees API.
+- `DEFAULT_GIT_TREES_PER_PAGE`: **1000**: Default and maximum number of items per page for Git trees API.
 - `DEFAULT_MAX_BLOB_SIZE`: **10485760**: Default max size of a blob that can be return by the blobs API.
 
 ## OAuth2 (`oauth2`)

docs/content/doc/advanced/customizing-gitea.en-us.md

 
 ### Locales
 
-Locales are managed via our [crowdin](https://crowdin.com/project/gitea).
+Locales are managed via our [Crowdin](https://crowdin.com/project/gitea).
 You can override a locale by placing an altered locale file in `$GITEA_CUSTOM/options/locale`.
 Gitea's default locale files can be found in the [`options/locale`](https://github.com/go-gitea/gitea/tree/main/options/locale) source folder and these should be used as examples for your changes.
 

docs/content/doc/advanced/protected-tags.en-us.md

 
 # Protected tags
 
-Protected tags allow control over who has permission to create or update git tags. Each rule allows you to match either an individual tag name, or use an appropriate pattern to control multiple tags at once. 
+Protected tags allow control over who has permission to create or update Git tags. Each rule allows you to match either an individual tag name, or use an appropriate pattern to control multiple tags at once. 
 
 **Table of Contents**
 

docs/content/doc/advanced/signing.en-us.md

 
 Gitea will verify GPG commit signatures in the provided tree by
 checking if the commits are signed by a key within the Gitea database,
-or if the commit matches the default key for git.
+or if the commit matches the default key for Git.
 
 Keys are not checked to determine if they have expired or revoked.
 Keys are also not checked with keyservers.
 Please note: The signer of a commit does not have to be an author or
 committer of a commit.
 
-This functionality requires git >= 1.7.9 but for full functionality
-this requires git >= 2.0.0.
+This functionality requires Git >= 1.7.9 but for full functionality
+this requires Git >= 2.0.0.
 
 ## Automatic Signing
 
 a signing key. Gitea generates all its commits using the server `git`
 command at present - and therefore the server `gpg` will be used for
 signing (if configured.) Administrators should review best-practices
-for gpg - in particular it is probably advisable to only install a
+for GPG - in particular it is probably advisable to only install a
 signing secret subkey without the master signing and certifying secret
 key.
 
 `commit.gpgsign` option - if this is set, then it will use the results
 of the `user.signingkey`, `user.name` and `user.email` as appropriate.
 
-Please note: by adjusting git's `config` file within Gitea's
+Please note: by adjusting Git's `config` file within Gitea's
 repositories, `SIGNING_KEY=default` could be used to provide different
 signing keys on a per-repository basis. However, this is clearly not an
 ideal UI and therefore subject to change.

docs/content/doc/developers/api-usage.en-us.md

 
 API Reference guide is auto-generated by swagger and available on:
 `https://gitea.your.host/api/swagger`
-or on
-[gitea demo instance](https://try.gitea.io/api/swagger)
+or on the
+[Gitea demo instance](https://try.gitea.io/api/swagger)
 
 The OpenAPI document is at:
 `https://gitea.your.host/swagger.v1.json`

docs/content/doc/developers/guidelines-backend.md

 To maintain understandable code and avoid circular dependencies it is important to have a good code structure. The Gitea backend is divided into the following parts:
 
 - `build`: Scripts to help build Gitea.
-- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by git or openSSH. Other sub commands could help to maintain Gitea.
+- `cmd`: All Gitea actual sub commands includes web, doctor, serv, hooks, admin and etc. `web` will start the web service. `serv` and `hooks` will be invoked by Git or OpenSSH. Other sub commands could help to maintain Gitea.
 - `integrations`: Integration tests
 - `models`: Contains the data structures used by xorm to construct database tables. It also contains functions to query and update the database. Dependencies to other Gitea code should be avoided. You can make exceptions in cases such as logging.
   - `models/db`: Basic database operations. All other `models/xxx` packages should depend on this package. The `GetEngine` function should only be invoked from `models/`.

docs/content/doc/developers/hacking-on-gitea.en-us.md

   - The binary is called `mingw32-make.exe` instead of `make.exe`. Add the `bin` folder to `PATH`.
 - [Chocolatey package](https://chocolatey.org/packages/make). Run `choco install make`
 
-**Note**: If you are attempting to build using make with Windows Command Prompt, you may run into issues. The above prompts (git bash, or mingw) are recommended, however if you only have command prompt (or potentially powershell) you can set environment variables using the [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) command, e.g. `set TAGS=bindata`.
+**Note**: If you are attempting to build using make with Windows Command Prompt, you may run into issues. The above prompts (Git bash, or MinGW) are recommended, however if you only have command prompt (or potentially PowerShell) you can set environment variables using the [set](https://docs.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) command, e.g. `set TAGS=bindata`.
 
 ## Downloading and cloning the Gitea source code
 
 database types using:
 
 ```bash
-make test-sqlite-migration # with sqlite switched for the appropriate database
+make test-sqlite-migration # with SQLite switched for the appropriate database
 ```
 
 ## Testing
 TAGS="bindata sqlite sqlite_unlock_notify" make build test-sqlite
 ```
 
-will run the integration tests in an sqlite environment. Integration tests
+will run the integration tests in an SQLite environment. Integration tests
 require `git lfs` to be installed. Other database tests are available but
 may need adjustment to the local environment.
 
 ```
 
 You will require a copy of [Hugo](https://gohugo.io/) to run this task. Please
-note: this may generate a number of untracked git objects, which will need to
+note: this may generate a number of untracked Git objects, which will need to
 be cleaned up.
 
 ## Visual Studio Code

docs/content/doc/developers/migrations.en-us.md

 # Migration Features
 
 Complete migrations were introduced in Gitea 1.9.0. It defines two interfaces to support migrating
-repository data from other git host platforms to Gitea or, in the future, migrating Gitea data to other
-git host platforms.  
-Currently, migrations from Github, Gitlab, and other Gitea instances are implemented.
+repository data from other Git host platforms to Gitea or, in the future, migrating Gitea data to other
+Git host platforms.  
+Currently, migrations from GitHub, GitLab, and other Gitea instances are implemented.
 
 First of all, Gitea defines some standard objects in packages [modules/migration](https://github.com/go-gitea/gitea/tree/main/modules/migration).  
 They are `Repository`, `Milestone`, `Release`, `ReleaseAsset`, `Label`, `Issue`, `Comment`, `PullRequest`, `Reaction`, `Review`, `ReviewComment`.
 
 ## Downloader Interfaces
 
-To migrate from a new git host platform, there are two steps to be updated.
+To migrate from a new Git host platform, there are two steps to be updated.
 
 - You should implement a `Downloader` which will be used to get repository information.
 - You should implement a `DownloaderFactory` which will be used to detect if the URL matches and create the above `Downloader`.

docs/content/doc/features/authentication.en-us.md

     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://github.com/go-gitea/gitea/blob/master/custom/conf/app.example.ini)
+    app.ini](https://github.com/go-gitea/gitea/blob/main/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 Gitea and
     which users will be synchronized. When initially run the task will create

docs/content/doc/features/webhooks.en-us.md

 
 # Webhooks
 
-Gitea supports web hooks for repository events. This can be configured in the settings
+Gitea 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.
 All event pushes are POST requests. The methods currently supported are:
 

docs/content/doc/help/faq.en-us.md

 The 1.7 and 1.7.0 directories are **not** the same. The 1.7 directory is built on each merged commit to the [`release/v1.7`](https://github.com/go-gitea/gitea/tree/release/v1.7) branch.  
 The 1.7.0 directory, however, is a build that was created when the [`v1.7.0`](https://github.com/go-gitea/gitea/releases/tag/v1.7.0) tag was created.
 
-This means that 1.x downloads will change as commits are merged to their respective branch (think of it as a separate "master" branch for each release).  
+This means that 1.x downloads will change as commits are merged to their respective branch (think of it as a separate "main" branch for each release).  
 On the other hand, 1.x.x downloads should never change.
 
 ## How to migrate from Gogs/GitHub/etc. to Gitea
 In order to migrate items such as issues, pull requests, etc. you will need to input at least your username.  
 [Example (requires login)](https://try.gitea.io/repo/migrate)
 
-To migrate from Gitlab to Gitea, you can use this non-affiliated tool:  
+To migrate from GitLab to Gitea, you can use this non-affiliated tool:  
 https://github.com/loganinak/MigrateGitlabToGogs
 
 ## Where does Gitea store what file
 - On the client:
   - Ensure the public and private ssh keys are added to the correct Gitea user.
   - Make sure there are no issues in the remote url. In particular, ensure the name of the
-    git user (before the `@`) is spelled correctly.
+    Git user (before the `@`) is spelled correctly.
   - Ensure public and private ssh keys are correct on client machine.
 - On the server:
   - Make sure the repository exists and is correctly named.

docs/content/doc/installation/from-binary.en-us.md

 
 ## Verify GPG signature
 Gitea signs all binaries with a [GPG key](https://keys.openpgp.org/search?q=teabot%40gitea.io) to prevent against unwanted modification of binaries.
-To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the gpg command line tool.
+To validate the binary, download the signature file which ends in `.asc` for the binary you downloaded and use the GPG command line tool.
 
 ```sh
 gpg --keyserver keys.openpgp.org --recv 7C9E68152594688862D62AF62D9AE806EC1592E2
 Gitea binary, usually producing an error such as ```./gitea: /lib/x86_64-linux-gnu/libc.so.6:
 version `GLIBC\_2.14' not found (required by ./gitea)```. This is due to the integrated
 SQLite support in the binaries provided by dl.gitea.io. In this situation, it is usually
-possible to [install from source]({{< relref "from-source.en-us.md" >}}) without sqlite
+possible to [install from source]({{< relref "from-source.en-us.md" >}}) without SQLite
 support.
 
 ### Running Gitea on another port
 ### Git error after updating to a new version of Gitea
 
 If the binary file name has been changed during the update to a new version of Gitea,
-git hooks in existing repositories will not work any more. In that case, a git
+Git Hooks in existing repositories will not work any more. In that case, a Git
 error will be displayed when pushing to the repository.
 
 ```
 
 To solve this, go to the admin options and run the task `Resynchronize pre-receive,
 update and post-receive hooks of all repositories` to update all hooks to contain
-the new binary path. Please note that this overwrite all git hooks including ones
+the new binary path. Please note that this overwrite all Git Hooks including ones
 with customizations made.
 
 If you aren't using the built-in to Gitea SSH server you will also need to re-write

docs/content/doc/installation/from-source.en-us.md

 ## Download
 
 First, we must retrieve the source code. Since, the advent of go modules, the
-simplest way of doing this is to use git directly as we no longer have to have
-gitea built from within the GOPATH.
+simplest way of doing this is to use Git directly as we no longer have to have
+Gitea built from within the GOPATH.
 
 ```bash
 git clone https://github.com/go-gitea/gitea
 - `pam`: Enable support for PAM (Linux Pluggable Authentication Modules). Can
   be used to authenticate local users or extend authentication to methods
   available to PAM.
-* `gogit`: (EXPERIMENTAL) Use go-git variants of git commands.
+* `gogit`: (EXPERIMENTAL) Use go-git variants of Git commands.
 
 Bundling assets into the binary using the `bindata` build tag is recommended for
 production deployments. It is possible to serve the static assets directly via a reverse proxy,

docs/content/doc/installation/run-as-service-in-ubuntu.en-us.md

 
 #### Using systemd
 
-Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/master/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
+Copy the sample [gitea.service](https://github.com/go-gitea/gitea/blob/main/contrib/systemd/gitea.service) to `/etc/systemd/system/gitea.service`, then edit the file with your favorite editor.
 
 Uncomment any service that needs to be enabled on this host, such as MySQL.
 
 ```
 
 Append the configuration from the sample
-[supervisord config](https://github.com/go-gitea/gitea/blob/master/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
+[supervisord config](https://github.com/go-gitea/gitea/blob/main/contrib/supervisor/gitea) to `/etc/supervisor/supervisord.conf`.
 
-Using your favorite editor, change the user (git) and home
-(/home/git) settings to match the deployment environment. Change the PORT
+Using your favorite editor, change the user (`git`) and home
+(`/home/git`) settings to match the deployment environment. Change the PORT
 or remove the -p flag if default port is used.
 
 Lastly enable and start supervisor at boot:

docs/content/doc/installation/windows-service.en-us.md

 
 ## Use absolute paths
 
-If you use sqlite3, change the `PATH` to include the full path:
+If you use SQLite3, change the `PATH` to include the full path:
 
 ```
 [database]

docs/content/doc/installation/with-docker-rootless.en-us.md

 possible to always use the latest stable tag or to use another service that handles updating
 Docker images.
 
-The rootless image use Gitea internal ssh to provide git protocol and doesn't support openssh.
+The rootless image use Gitea internal SSH to provide Git protocol and doesn't support OpenSSH.
 
 This reference setup guides users through the setup based on `docker-compose`, but the installation
 of `docker-compose` is out of scope of this documentation. To install `docker-compose` itself, follow

docs/content/doc/installation/with-docker.en-us.md

 
 ## Ports
 
-To bind the integrated openSSH daemon and the webserver on a different port, adjust
+To bind the integrated OpenSSH daemon and the webserver on a different port, adjust
 the port section. It's common to just change the host port and keep the ports within
 the container like they are.
 

docs/content/doc/usage/backup-and-restore.en-us.md

 
 # Backup and Restore
 
-Gitea currently has a `dump` command that will save the installation to a zip file. This
+Gitea currently has a `dump` command that will save the installation to a ZIP file. This
 file can be unpacked and used to restore an instance.
 
 **Table of Contents**
 
 - `app.ini` - Optional copy of configuration file if originally stored outside of the default `custom/` directory
 - `custom` - All config or customization files in `custom/`.
-- `data` - Data directory in <GITEA_WORK_DIR>, except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, sqlite file if you are using sqlite.
+- `data` - Data directory in <GITEA_WORK_DIR>, except sessions if you are using file session. This directory includes `attachments`, `avatars`, `lfs`, `indexers`, SQLite file if you are using SQLite.
 - `gitea-db.sql` - SQL dump of database
 - `gitea-repo.zip` - Complete copy of the repository directory.
 - `log/` - Various logs. They are not needed for a recovery or migration.
 service gitea restart
 ```
 
-Repository git-hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
+Repository Git Hooks should be regenerated if installation method is changed (eg. binary -> Docker), or if Gitea is installed to a different directory than the previous installation.
 
 With Gitea running, and from the directory Gitea's binary is located, execute: `./gitea admin regenerate hooks`
 
-This ensures that application and configuration file paths in repository git-hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.
+This ensures that application and configuration file paths in repository Git Hooks are consistent and applicable to the current installation. If these paths are not updated, repository `push` actions will fail.

docs/content/doc/usage/command-line.en-us.md

         - `gitea admin user change-password --username myname --password asecurepassword`
   - `regenerate`
     - Options:
-      - `hooks`: Regenerate git-hooks for all repositories
+      - `hooks`: Regenerate Git Hooks for all repositories
       - `keys`: Regenerate authorized_keys file
     - Examples:
       - `gitea admin regenerate hooks`
         - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
         - `--custom-email-url`: Use a custom Email URL (option for GitHub).
         - `--icon-url`: Custom icon URL for OAuth2 login source.
-        - `--override-local-2fa`: Allow source to override local 2fa. (Optional)
+        - `--override-local-2fa`: Allow source to override local 2FA. (Optional)
         - `--scopes`: Addtional scopes to request for this OAuth2 source. (Optional)
         - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
         - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
         - `--custom-profile-url`: Use a custom Profile URL (option for GitLab/GitHub).
         - `--custom-email-url`: Use a custom Email URL (option for GitHub).
         - `--icon-url`: Custom icon URL for OAuth2 login source.
-        - `--override-local-2fa`: Allow source to override local 2fa. (Optional)
+        - `--override-local-2fa`: Allow source to override local 2FA. (Optional)
         - `--scopes`: Addtional scopes to request for this OAuth2 source.
         - `--required-claim-name`: Claim name that has to be set to allow users to login with this source. (Optional)
         - `--required-claim-value`: Claim value that has to be set to allow users to login with this source. (Optional)
 
 ### dump-repo
 
-Dump-repo dumps repository data from git/github/gitea/gitlab:
+Dump-repo dumps repository data from Git/GitHub/Gitea/GitLab:
 
 - Options:
   - `--git_service service` : Git service, it could be `git`, `github`, `gitea`, `gitlab`, If clone_addr could be recognized, this could be ignored.

docs/content/page/index.en-us.md

         - MSSQL (>=2008R2 SP3)
         - TiDB (MySQL protocol)
     - Configuration file
-        - [app.ini](https://github.com/go-gitea/gitea/blob/master/custom/conf/app.example.ini)
+        - [app.ini](https://github.com/go-gitea/gitea/blob/main/custom/conf/app.example.ini)
     - Admin panel
         - Statistics
         - Actions
             - Maximum repositories
             - Disable account
             - Admin permissions
-            - Permission to create git hooks
+            - Permission to create Git Hooks
             - Permission to create organizations
             - Permission to import repositories
         - Organization management
                 - Clean up old archives
     - Environment variables
     - Command line options
-- Multi-language support ([21 languages](https://github.com/go-gitea/gitea/tree/master/options/locale))
+- Multi-language support ([21 languages](https://github.com/go-gitea/gitea/tree/main/options/locale))
 - [Mermaid](https://mermaidjs.github.io/) Diagram support
 - Mail service
     - Notifications
             - Default branch
             - Branch protection
         - Webhooks
-        - Git hooks
+        - Git Hooks
         - Deploy keys
 
 ## System Requirements
 - Gitea should be run with a dedicated non-root system account on UNIX-type systems.
    - Note: Gitea manages the `~/.ssh/authorized_keys` file. Running Gitea as a regular user could break that user's ability to log in.
 - [Git](https://git-scm.com/) version 1.7.2 or later is required. Version 1.9.0 or later is recommended. Also please note:
-   - Git [large file storage](https://git-lfs.github.com/) will be available if enabled when git >= 2.1.2.
-   - Git commit-graph rendering will be enabled automatically when git >= 2.18.
+   - [Git Large File Storage](https://git-lfs.github.com/) will be available if enabled when Git >= 2.1.2.
+   - Git commit-graph rendering will be enabled automatically when Git >= 2.18.
 
 ## Browser Support
 

integrations/README.md

 make test-sqlite
 ```
 
-## Run mysql integrations tests
-Setup a mysql database inside docker
+## Run MySQL integrations tests
+Setup a MySQL database inside docker
 ```
 docker run -e "MYSQL_DATABASE=test" -e "MYSQL_ALLOW_EMPTY_PASSWORD=yes" -p 3306:3306 --rm --name mysql mysql:latest #(just ctrl-c to stop db and clean the container)
 docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" --rm --name elasticsearch elasticsearch:7.6.0 #(in a second terminal, just ctrl-c to stop db and clean the container)
 
 Example command to run GPG test:
 
-For sqlite:
+For SQLite:
 
 ```
 make test-sqlite#GPG
 ```
 
-For other databases(replace MSSQL to MYSQL, MYSQL8, PGSQL):
+For other databases(replace `mssql` to `mysql`, `mysql8` or `pgsql`):
 
 ```
 TEST_MSSQL_HOST=localhost:1433 TEST_MSSQL_DBNAME=test TEST_MSSQL_USERNAME=sa TEST_MSSQL_PASSWORD=MwantsaSecurePassword1 make test-mssql#GPG

options/locale/locale_en-US.ini

 template.items = Template Items
 template.git_content = Git Content (Default Branch)
 template.git_hooks = Git Hooks
-template.git_hooks_tooltip = You are currently unable to modify or remove git hooks once added. Select this only if you trust the template repository.
+template.git_hooks_tooltip = You are currently unable to modify or remove Git Hooks once added. Select this only if you trust the template repository.
 template.webhooks = Webhooks
 template.topics = Topics
 template.avatar = Avatar
 migrate_repo = Migrate Repository
 migrate.clone_address = Migrate / Clone From URL
 migrate.clone_address_desc = The HTTP(S) or Git 'clone' URL of an existing repository
-migrate.github_token_desc = You can put one or more tokens with comma separated here to make migrating faster because of Github API rate limit. WARN: Abusing this feature may violate the service provider's policy and lead to account blocking.
+migrate.github_token_desc = You can put one or more tokens with comma separated here to make migrating faster because of GitHub API rate limit. WARN: Abusing this feature may violate the service provider's policy and lead to account blocking.
 migrate.clone_local_path = or a local server path
 migrate.permission_denied = You are not allowed to import local repositories.
 migrate.permission_denied_blocked = You can not import from disallowed hosts, please ask the admin to check ALLOWED_DOMAINS/ALLOW_LOCALNETWORKS/BLOCKED_DOMAINS settings.
 migrate.migrating_failed = Migrating from <b>%s</b> failed.
 migrate.migrating_failed.error = Error: %s
 migrate.migrating_failed_no_addr = Migration failed.
-migrate.github.description = Migrate data from github.com or other Github instances.
+migrate.github.description = Migrate data from github.com or other GitHub instances.
 migrate.git.description = Migrate a repository only from any Git service.
 migrate.gitlab.description = Migrate data from gitlab.com or other GitLab instances.
 migrate.gitea.description = Migrate data from gitea.com or other Gitea instances.
 create_new_repo_command = Creating a new repository on the command line
 push_exist_repo = Pushing an existing repository from the command line
 empty_message = This repository does not contain any content.
-broken_message = The git data underlying this repository cannot be read. Contact the administrator of this instance or delete this repository.
+broken_message = The Git data underlying this repository cannot be read. Contact the administrator of this instance or delete this repository.
 
 code = Code
 code.desc = Access source code, files, commits and branches.
 editor.no_changes_to_show = There are no changes to show.
 editor.fail_to_update_file = Failed to update/create file '%s'.
 editor.fail_to_update_file_summary = Error Message:
-editor.push_rejected_no_message = The change was rejected by the server without a message. Please check githooks.
-editor.push_rejected = The change was rejected by the server. Please check githooks.
+editor.push_rejected_no_message = The change was rejected by the server without a message. Please check Git Hooks.
+editor.push_rejected = The change was rejected by the server. Please check Git Hooks.
 editor.push_rejected_summary = Full Rejection Message:
 editor.add_subdir = Add a directory…
 editor.unable_to_upload_files = Failed to upload files to '%s' with error: %v
 pulls.unrelated_histories = Merge Failed: The merge head and base do not share a common history. Hint: Try a different strategy
 pulls.merge_out_of_date = Merge Failed: Whilst generating the merge, the base was updated. Hint: Try again.
 pulls.head_out_of_date = Merge Failed: Whilst generating the merge, the head was updated. Hint: Try again.
-pulls.push_rejected = Merge Failed: The push was rejected. Review the githooks for this repository.
+pulls.push_rejected = Merge Failed: The push was rejected. Review the Git Hooks for this repository.
 pulls.push_rejected_summary = Full Rejection Message
-pulls.push_rejected_no_message = Merge Failed: The push was rejected but there was no remote message.<br>Review the githooks for this repository
+pulls.push_rejected_no_message = Merge Failed: The push was rejected but there was no remote message.<br>Review the Git Hooks for this repository
 pulls.open_unmerged_pull_exists = `You cannot perform a reopen operation because there is a pending pull request (#%d) with identical properties.`
 pulls.status_checking = Some checks are pending
 pulls.status_checks_success = All checks were successful
 settings.webhook.headers = Headers
 settings.webhook.payload = Content
 settings.webhook.body = Body
-settings.githooks_desc = "Git hooks are powered by Git itself. You can edit hook files below to set up custom operations."
+settings.githooks_desc = "Git Hooks are powered by Git itself. You can edit hook files below to set up custom operations."
 settings.githook_edit_desc = If the hook is inactive, sample content will be presented. Leaving content to an empty value will disable this hook.
 settings.githook_name = Hook Name
 settings.githook_content = Hook Content