wiki markdown: openwrt naming fixes and contribution improvement

Signed-off-by: Sander <[email protected]>

CONTRIBUTING.md

@@ -11,31 +11,34 @@ guidelines:
   be updated regularly with supported versions.
 - Have no dependencies outside the OpenWrt core packages or this repository
   feed.
-- Have been tested to compile with the correct includes and dependencies.
-  Please also test with "Compile with full language support" found under
-  "General Build Settings" set if language support is relevant to your package.
-- Best of all -- it works as expected!
+- The compilation has been successfully tested with the appropriate includes and dependencies. 
+  Additionally, if language support is relevant to your package, please enable the "Compile with full language support" option found under "Global Build Settings" in "menuconfig" and conduct further tests.
+- Most important -- the packaged software is tested to work as expected!
 
 ## Package Sources (archives and repositories)
 
-- PKG_SOURCE should reference the smallest available archive. In order of
-  preference: xz (most compressed), bzip2, gz and zip. As a last resort,
-  downloads from source repositories can be used.
-- PKG_SOURCE_URL should link to an official release archive. Use of HTTPS:
-  is preferred. If a source archive is not available, a locally generated
+- <strong>PKG_SOURCE</strong> should reference the smallest available archive. In order of
+  preference: 
+  1. xz (most compressed), 
+  1. bzip2, gz and zip. 
+  1. As a last resort downloads from source repositories can be used.
+- <strong>PKG_SOURCE_URL</strong> should link to an official release archive. Use of `https://`
+  is preferred. 
+
+  If a source archive is not available, a locally generated
   archive fetched using git, svn, cvs or in rare circumstances, hg or bzr.
 - Convenience macros for popular mirrors are defined. Using these macros will
   make your package downloads more robust by mapping to a list of possible
   source mirrors for archive availability.
-  - @SF - SourceForge (downloads.sourceforge.net) with 5 retries due to
+  - `@SF` - SourceForge (downloads.sourceforge.net) with 5 retries due to
     re-directs
-  - @GITHUB - GitHub (raw.githubusercontent.com) with 5 retries due to
+  - `@GITHUB` - GitHub (raw.githubusercontent.com) with 5 retries due to
     re-directs
-  - @GNU - 8 regional servers
-  - @GNOME - 8 regional servers
-  - @SAVANNAH - 8 regional servers
-  - @APACHE - 8 regional servers
-  - @KERNEL - Linux kernel archives & mirrors
+  - `@GNU` - 8 regional servers
+  - `@GNOME` - 8 regional servers
+  - `@SAVANNAH` - 8 regional servers
+  - `@APACHE` - 8 regional servers
+  - `@KERNEL` - Linux kernel archives & mirrors
 - Please _DO NOT_ use an archive which changes over time. A version labeled
   "latest" is not constant each download. Also, using the head of a branch will
   create unpredictable results which can be different each build.
@@ -47,31 +50,31 @@ guidelines:
   contract to OpenWrt. Assigning a Copyright to yourself or organization you
   represent is acceptable.
 - A (PKG\_)MAINTAINER definition listing either yourself and/or another person
-  responsible for this package (E.g.: PKG_MAINTAINER:= Joe D. Hacker
-  `<[email protected]`>). Listing multiple maintainers is encouraged in
+  responsible for this package (E.g.: `PKG_MAINTAINER:= Joe D. Hacker
+  <[email protected]>`). Listing multiple maintainers is encouraged in
   order to keep the package active and up-to-date. Leaving this blank will also
   be accepted, however the review process may not be as quick as one with a
   maintainer.
-- A PKG_LICENSE tag declaring the main license of the package.  (E.g.:
+- A <strong>PKG_LICENSE</strong> tag declaring the main license of the package.  (E.g.:
   PKG_LICENSE:=GPL-2.0-or-later) Please use SPDX identifiers if possible (see
   list at the bottom).
-- An optional PKG_LICENSE_FILES tag including the filenames of the
+- An optional <strong>PKG_LICENSE_FILES</strong> tag including the filenames of the
   license-files in the source-package.  (E.g.: PKG_LICENSE_FILES:=COPYING)
-- PKG_RELEASE should be initially set to 1 or reset to 1 if the software
+- <strong>PKG_RELEASE</strong> should be initially set to `1` or reset to `1` if the software
   version is changed. You should increment it if the package itself has
   changed. For example, modifying a support script, changing configure options
   like --disable_ or --enable\_ switches, or if you changed something in the
   package which causes the resulting binaries to be different. Changes like
   correcting md5sums, changing mirror URLs, adding a maintainer field or updating
   a comment or copyright year in a Makefile do not require a change to
   PKG_RELEASE.
-- Avoid reuse of PKG_NAME in call, define and eval lines to improve
+- Avoid reuse of <strong>PKG_NAME</strong> in call, define and eval lines to improve
   readability.
 
 ### Commits in your pull-requests should
 
-- Have a useful commit subject prefixed with the package name (E.g.: "foopkg:
-  Add libzot dependency").
+- Have a useful commit subject prefixed with the package name (E.g.: `foopkg:
+  Add libzot dependency`).
 - Include Signed-off-by tag in the commit comments.  See: [Sign your
   work](https://openwrt.org/submitting-patches#sign_your_work)
 - Author and sign-off must match and be a real name or known identity and
@@ -119,27 +122,27 @@ commenting and amending the proposed changes.
 
 ## If you have commit access
 
-- Do NOT use git push --force.
+- Do NOT use `git push --force`.
 - Do NOT commit to other maintainer's packages without their consent.
 - Use Pull Requests if you are unsure and to suggest changes to other
   maintainers.
 
 ### Gaining commit access
 
 - We will gladly grant commit access to responsible contributors who have made
-  useful pull requests and / or feedback or patches to this repository or
+  useful pull requests and/or feedback or patches to this repository or
   OpenWrt in general. Please include your request for commit access in your next
   pull request or ticket.
 
 ## Release Branches
 
 - Old stable branches were named after the following pattern "for-XX.YY" (e.g.
-  for-14.07) before the LEDE split.  During the LEDE split there was only one
-  release branch with the name "lede-17.01".  After merging the LEDE fork with
+  for-14.07) before the LEDE split. During the LEDE split there was only one
+  release branch with the name "lede-17.01". After merging the LEDE fork with
   OpenWrt the release branches are named according to the following pattern
-  "openwrt-XX.YY" (e.g. openwrt-18.06).
+  "openwrt-XX.YY" (e.g. `openwrt-18.06`).
 - These branches are built with the respective OpenWrt release and are created
-  during the release stabilisation phase.
+  during the release stabilization phase.
 - Please ONLY cherry-pick or commit security and bug-fixes to these branches.
 - Do NOT add new packages and do NOT do major upgrades of packages here.
 - If you are unsure if your change is suitable, please use a pull request.

net/apfree-wifidog/README.md

@@ -3,9 +3,9 @@
 
 [![license][1]][2]
 [![PRs Welcome][3]][4]
-[![Issue Welcome][5]][6]
+[![Issues Welcome][5]][6]
 [![Release Version][7]][8]
-[![OpenWRT][11]][12]
+[![OpenWrt][11]][12]
 [![Join the QQ Group][15]][16]
 
 
@@ -17,7 +17,7 @@
 [6]: https://github.com/liudf0716/apfree_wifidog/issues/new
 [7]: https://img.shields.io/badge/release-3.11.1716-red.svg?style=plastic
 [8]: https://github.com/liudf0716/apfree_wifidog/releases
-[11]: https://img.shields.io/badge/Platform-%20OpenWRT%7C%20LEDE%20-brightgreen.svg?style=plastic
+[11]: https://img.shields.io/badge/Platform-%20OpenWrt%7C%20LEDE%20-brightgreen.svg?style=plastic
 [12]: https://github.com/KunTengRom/kunteng-lede-17.01.4
 [13]: https://img.shields.io/badge/KunTeng-Inside-blue.svg?style=plastic
 [14]: https://www.kunteng.org.cn
@@ -26,7 +26,7 @@
 
 ## ApFree WiFiDog: A high performance captive portal solution for HTTP(s)
 
-ApFree WiFiDog is a high performance captive portal solution for HTTP(s), which mainly used in ([LEDE](https://github.com/lede-project/source)&[Openwrt](https://github.com/openwrt/openwrt)) platform. 
+ApFree WiFiDog is a high performance captive portal solution for HTTP(s), which mainly used in ([LEDE](https://github.com/lede-project/source) & [OpenWrt](https://github.com/openwrt/openwrt)) platform. 
 
 
 **[中文介绍](https://github.com/liudf0716/apfree_wifidog/blob/master/README_ZH.md)**
@@ -37,7 +37,7 @@ In fact, the title should be why we choose apfree-wifidog, the reason was the fo
 
 >  Stable
 
-apfree-wifidog was widely used in tens of thousands device, which were running in business scene. In order to improve its stable, we rewrite all iptables rule by api instead of fork call, which will easily cause deadlock in multithread-fork running environment. we also re-write the code and replace libhttpd (which unmaitained for years) with libevent
+apfree-wifidog was widely used in tens of thousands device, which were running in business scene. In order to improve its stable, we rewrite all iptables rule by api instead of fork call, which will easily cause deadlock in multithread-fork running environment. we also re-write the code and replace libhttpd (which is unmaintained for years) with libevent
 
 > Performance
 
@@ -54,9 +54,9 @@ apfree-wifidog support mac temporary-pass, ip,domain,pan-domain,white-mac,black-
 
 > MQTT support
 
-by enable mqtt support, u can remotely deliver such as trusted ip, domian and pan-domain rules to apfree wifidog 
+by enable mqtt support, u can remotely deliver such as trusted ip, domain and pan-domain rules to apfree wifidog 
 
-> Compitable with wifidog protocol
+> Compilable with wifidog protocol
 
 u don't need to modify your wifidog authentication server to adapt apfree-wifidog; if u have pression on server-side, apfree wifidog's improved protocol can greatly relieve it, which disabled by default
 
@@ -91,7 +91,7 @@ config wifidog
 
 ### How to support https redirect
 
-In order to support https redirect, apfree-wifidog need x509 pem cert and private key, u can generate youself like this:
+In order to support https redirect, apfree-wifidog need x509 pem cert and private key, u can generate yourself like this:
 
 ```
 PX5G_BIN="/usr/sbin/px5g"

net/geoip-shell/README.md

@@ -119,14 +119,14 @@ _<details><summary>Example</summary>_
 On OpenWrt, if installed via an ipk package: `opkg uninstall <geoip-shell|geoip-shell-iptables>`
 
 ## **Pre-requisites**
-- **Linux**. Tested on Debian-like systems and on OPENWRT, should work on any desktop/server distribution and possibly on some other embedded distributions.
+- **Linux**. Tested on Debian-like systems and on OpenWrt, should work on any desktop/server distribution and possibly on some other embedded distributions.
 - **POSIX-compliant shell**. Works on most relatively modern shells, including **bash**, **dash**, **ksh93**, **yash** and **ash** (including Busybox **ash**). Likely works on **mksh** and **lksh**. Other flavors of **ksh** may or may not work _(please let me know if you try them)_. Does **not** work on **tcsh** and **zsh**.
 
 - **nftables** - firewall management utility. Supports nftables 1.0.2 and higher (may work with earlier versions but I do not test with them).
 - OR **iptables** - firewall management utility. Should work with any relatively modern version.
 - for **iptables**, requires the **ipset** utility - install it using your distribution's package manager
 - standard Unix utilities including **tr**, **cut**, **sort**, **wc**, **awk**, **sed**, **grep**, **pgrep**, **pidof** and **logger** which are included with every server/desktop linux distribution (and with OpenWrt). Both GNU and non-GNU versions are supported, including BusyBox implementation.
-- **wget** or **curl** or **uclient-fetch** (OpenWRT-specific utility).
+- **wget** or **curl** or **uclient-fetch** (OpenWrt-specific utility).
 - for the autoupdate functionality, requires the **cron** service to be enabled.
 
 ## **Notes**

net/stubby/files/README.md

@@ -1,5 +1,5 @@
 
-# Stubby for OpenWRT
+# Stubby for OpenWrt
 
 ## Stubby Description
 
@@ -8,9 +8,9 @@ an application that acts as a local DNS Privacy stub resolver (using
 DNS-over-TLS). Stubby encrypts DNS queries sent from a client machine to a DNS
 Privacy resolver increasing end user privacy.
 
-Stubby is useful on an OpenWRT device, because it can sit between the usual DNS
+Stubby is useful on an OpenWrt device, because it can sit between the usual DNS
 resolver (dnsmasq by default) and the upstream DNS resolver and be used to
-ensure that DNS traffic is encrypted between the OpenWRT device and the
+ensure that DNS traffic is encrypted between the OpenWrt device and the
 resolver.
 
 Stubby is developed by the [getdns](http://getdnsapi.net/) project.
@@ -31,7 +31,7 @@ will also install the required dependency packages, including the
 The default configuration of the package has been chosen to ensure that stubby
 should work after installation.
 
-By default, configuration of stubby is integrated with the OpenWRT UCI system
+By default, configuration of stubby is integrated with the OpenWrt UCI system
 using the file `/etc/config/stubby`. The configuration options available are
 also documented in that file. If for some reason you wish to configure stubby
 using the `/etc/stubby/stubby.yml` file, then you simply need to set `option
@@ -42,7 +42,7 @@ manual '1'` in `/etc/config/stubby` and all other settings in
 
 The default configuration ensures that stubby listens on port 5453 on the
 loopback interfaces for IPv4 and IPv6. As such, by default, stubby will respond
-only to lookups from the OpenWRT device itself.
+only to lookups from the OpenWrt device itself.
 
 By setting the listening ports to non-standard values, this allows users to keep
 the main name server daemon in place (dnsmasq/unbound/etc.) and have that name
@@ -70,14 +70,14 @@ list](https://dnsprivacy.org/wiki/display/DP/DNS+Privacy+Test+Servers).
 
 ## Integration of stubby with dnsmasq
 
-The recommended way to use stubby on an OpenWRT device is to integrate it with a
-caching resolver. The default caching resolver in OpenWRT is dnsmasq.
+The recommended way to use stubby on an OpenWrt device is to integrate it with a
+caching resolver. The default caching resolver in OpenWrt is dnsmasq.
 
 ### Set dnsmasq to send DNS requests to stubby
 
-Since dnsmasq responds to LAN DNS requests on port 53 of the OpenWRT device by
+Since dnsmasq responds to LAN DNS requests on port 53 of the OpenWrt device by
 default, all that is required is to have dnsmasq forward those requests to
-stubby which is listening on port 5453 of the OpenWRT device. To achieve this,
+stubby which is listening on port 5453 of the OpenWrt device. To achieve this,
 we need to set the `server` option in the dnsmasq configuration in the
 `/etc/config/dhcp` file to `'127.0.0.1#5453'`. We also need to tell dnsmasq not
 to use resolvers found in `/etc/resolv.conf` by setting the dnsmasq option
@@ -100,7 +100,7 @@ The same outcome can be achieved in the LUCI web interface as follows:
 
 The configuration changes in the previous section ensure that DNS queries are
 sent over TLS encrypted connections *once dnsmasq and stubby are started*. When
-the OpenWRT device is first brought up, there is a possibility that DNS queries
+the OpenWrt device is first brought up, there is a possibility that DNS queries
 can go to ISP provided DNS servers ahead of dnsmasq and stubby being active. In
 order to mitigate this leakage, it's necessary to ensure that upstream resolvers
 aren't available, and the only DNS resolver used by the system is
@@ -145,7 +145,7 @@ DNSSEC:
 Either option achieves the same outcome, and there appears to be little reason
 for choosing one over the other other than that the second option is easier to
 configure in the LUCI web interface. Both options are detailed below, and both
-require that the `dnsmasq` package on the OpenWRT device is replaced with the
+require that the `dnsmasq` package on the OpenWrt device is replaced with the
 `dnsmasq-full` package. That can be achieved by running the following command:
 
     opkg install dnsmasq-full --download-only && opkg remove dnsmasq && opkg install dnsmasq-full --cache . && rm *.ipk