Fix capitalisation

source/conf.py

@@ -340,7 +340,7 @@ epub_copyright = copyright
 # A unique identification for the text.
 #epub_uid = ''
 
-# A tuple containing the cover image and cover page html template filenames.
+# A tuple containing the cover image and cover page HTML template filenames.
 #epub_cover = ()
 
 # A sequence of (type, uri, title) tuples for the guide element of content.opf.

source/development/examples/helloworld.rst

@@ -66,7 +66,7 @@ Architecture
 
 Always make sure there's a clear separation of concerns, back-end calls
 (like shell scripts) should be implemented using the configd system, all
-communication to the client should be handled from an api endpoint. (the
+communication to the client should be handled from an API endpoint. (the
 example provides more insights on how this works).
 
 Back-end programs should not access the config.xml directly, if data is
@@ -215,7 +215,7 @@ retrieval/changing of configuration data.
 They should live in a subdirectory of the controller called Api and
 extend the corresponding class.
 
-For our modules we create two api controllers, one for controlling
+For our modules we create two API controllers, one for controlling
 settings and one for performing service actions. (Named
 SettingsController.php and ServiceController.php) Both should look like
 this (replace Settings with Service for the other one):
@@ -377,7 +377,7 @@ something like this:
     {{ partial("layout_partials/base_form",['fields':generalForm,'id':'frm_GeneralSettings'])}}
 
 This tells the template system to add a form using the contents of
-generalForm and name it frm\_GeneralSettings in the html page. Based on
+generalForm and name it frm\_GeneralSettings in the HTML page. Based on
 a standard template part which is already part of the standard system,
 named base\_form.volt.
 
@@ -760,7 +760,7 @@ elements:
         });
     });
 
-(in html section)
+(in HTML section)
 
 .. code-block:: xml
 
@@ -868,7 +868,7 @@ content in it:
     </acl>
 
 This creates an acl key named “page-user-helloworld” which authorizes
-access to both the ui and api urls of this application. You can now
+access to both the ui and API urls of this application. You can now
 grant access to this module from the system user manager.
 
 |

source/development/frontend/controller.rst

@@ -86,7 +86,7 @@ A simple index controller to echo a request back looks like this:
         }
     }
 
-When placed inside the api directory of Vendor/Sample can be called by sending a
+When placed inside the API directory of Vendor/Sample can be called by sending a
 post request to /api/sample/test/echo, using jquery:
 
 .. code-block:: javascript

source/development/frontend/routing.rst

@@ -62,14 +62,14 @@ This routing is setup via the index page of our new code base and uses
 API routing
 -----------
 
-Routing for api functions is quite similar to routing UI components,
+Routing for API functions is quite similar to routing UI components,
 just create a Api directory under the app path and place a controller
 class to handle the request. The only major difference is that it's
 handled by a separate php file (called api.php) in stead of the
 index.php file used to configure the ui part, details of the routing can
 be found in /usr/local/opnsense/mvc/app/config/services\_api.php .
 
-If our sample app needs an api to echo something back via a controller called
+If our sample app needs an API to echo something back via a controller called
 tools it could be put into a file called:
 
 ::

source/development/guidelines/basics.rst

@@ -49,7 +49,7 @@ time and we needed to transition that into something more structured.
 One of the first things (on the programming part of the system) we did was build
 components around an existing framework (`Phalcon <https://phalconphp.com/>`_)
 to create new modules, which could use validated configuration data (from the
-config.xml), supply a RESTful API and generate html output using standard
+config.xml), supply a RESTful API and generate HTML output using standard
 templates (Volt).
 
 We created the configd system, which can generate system configuration and
@@ -78,7 +78,7 @@ implementation is one example of this stage.
 
 **3)** Moving on
 (re)build new parts, using our new modules, which provide a layered development
-system to automatically support api calls from other systems and xml based model
+system to automatically support API calls from other systems and xml based model
 templates to describe configuration data.
 
 *See also:*
@@ -87,7 +87,7 @@ templates to describe configuration data.
 * :doc:`Howto use the API </development/how-tos/api>`
 
 Our guidelines somewhat depend of the stage the code is in, when writing new code,
-all actions should use the api system for actually changing configuration and
+all actions should use the API system for actually changing configuration and
 performing configuration tasks. They should, of course, use the normal PSR coding
 standards for PHP code and follow the Python PEPs.
 

source/development/how-tos/api.rst

@@ -23,7 +23,7 @@ Creating keys
 
 API keys are managed in the user manager (system\_usermanager.php), go
 to the user manager page and select a user. Somewhere down the page you
-will find the api section for this user.
+will find the API section for this user.
 
 |Usermanager add api key.png|
 

source/manual/how-tos/cloud_backup.rst

@@ -67,7 +67,7 @@ First we need to have a project in the google developer console:
 
    -  In the left menu APIs -> "Drive API" -> Enable
 
--  Open the project and start to create an api key
+-  Open the project and start to create an API key
 
    -  In the left menu : APIs & auth -> Credentials
    -  Click on the button "Create new Client ID"

source/manual/how-tos/guestnet.rst

@@ -241,7 +241,7 @@ Unpack the template zip file, you should have something similar to this:
 
 Most files of the template can be modified, but some are default and may not be
 changes. Upon upload any changes to the files listed in **exclude.list** will be
-ignored. Currently these include the bootstrap java scripting and some fonts.
+ignored. Currently these include the bootstrap JavaScript and some fonts.
 
 With the captive portal enabled the default screen looks like:
 
@@ -536,15 +536,15 @@ the correct database (Wifi day pass in our example).
 Advanced - Session popup
 ------------------------
 Let's create a Session Popup so users can see some details about their session and
-Logout. For this feature we will use OPNsense's built-in api calls.
+Logout. For this feature we will use OPNsense's built-in API calls.
 
-In particular we will use the following api call (for zone id 0):
+In particular we will use the following API call (for zone id 0):
 
 .. code-block:: guess
 
   /api/captiveportal/access/status/0/
 
-The response on this api call looks like this (for an active session):
+The response on this API call looks like this (for an active session):
 
 .. code-block:: json
 
@@ -563,7 +563,7 @@ The response on this api call looks like this (for an active session):
   "packets_in":3181,
   "clientState":"AUTHORIZED"}
 
-It would go a bit to far to explain standard html and java scripting used for
+It would go a bit to far to explain standard HTML and JavaScript used for
 our simple popup, but a full demo template can be downloaded:
 
 :download:`Download the example Template (with popup) <resources/template_popup.zip>`