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

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

@@ -110,8 +110,8 @@ the `token=` string in a GET request.
 
 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

@@ -32,7 +32,7 @@ So it's very important to manage these packages. Please take the below guideline
 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

@@ -73,7 +73,7 @@ One of these three distributions of Make will run on Windows:
   - 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
 
@@ -264,7 +264,7 @@ in `models/migrations/`. You can ensure that your migrations work for the main
 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
@@ -282,7 +282,7 @@ have written integration tests; however, these are database dependent.
 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.
 
@@ -308,7 +308,7 @@ make trans-copy clean build
 ```
 
 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

@@ -16,16 +16,16 @@ menu:
 # 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`.