Extends textlint Terminology list; part 5

.textlintrc.json

@@ -9,6 +9,7 @@
       "skip": ["Blockquote"],
       "terms": [
         " API ",
+        "2FA",
         "ABB Solar PV",
         "ABB",
         "Abode",
@@ -88,7 +89,10 @@
         "GitHub",
         "Google Assistant",
         "Google Home",
+        "Google Wifi",
         "Google",
+        "GraphiQL",
+        "GraphQL",
         "Home Assistant Companion",
         "Home Assistant Core",
         "Home Assistant Operating System",
@@ -115,12 +119,16 @@
         "LED",
         "Let's Encrypt",
         "Life360",
+        "LinkedIn",
         "Linky",
         "Linux",
         "Lovelace",
+        "MacBook",
         "macOS",
+        "Markdown",
         "Microsoft",
         "MikroTik",
+        "MIME",
         "MJPEG",
         "MQTT",
         "NAS",
@@ -129,6 +137,7 @@
         "NodeMCU",
         "Norway",
         "OpenWrt",
+        "PayPal",
         "PDU",
         "Philips",
         "PlayStation",
@@ -210,19 +219,35 @@
         "Ziggo",
         "ZoneMinder",
         [" HA ", "Home Assistant"],
+        ["\\(s\\)he", "they"],
+        ["2 ?steps? authentication", "two-step authentication"],
         ["Alarm ?dot ?com", "Alarm.com"],
         ["an URL", "a URL"],
         ["API['’]?s", "APIs"],
+        ["backwards compatible", "backward compatible"],
+        ["client ?side", "client-side"],
+        ["colour", "color"],
         ["DarkSky", "Dark Sky"],
+        ["end ?to ?end", "end-to-end"],
         ["FRITZ!? ?Box", "FRITZ!Box"],
         ["hass", "Home Assistant"],
+        ["he or she", "they"],
+        ["he/she", "they"],
         ["Home-?Ass?s?iss?tt?ant", "Home Assistant"],
         ["ISY ?994", "ISY994"],
         ["Mac ?OS", "macOS"],
         ["OS ?X", "macOS"],
+        ["repo\\b", "repository"],
+        ["config\\b", "configuration"],
         ["Sky Bell", "SkyBell"],
         ["Sleep IQ", "SleepIQ"],
         ["Twill?o", "Twilio"],
+        ["analyse", "analyze"],
+        ["recognise", "recognize"],
+        ["travelled", "traveled"],
+        ["licence", "license"],
+        ["behaviour", "behavior"],
+        ["two ?steps? authentication", "two-step authentication"],
         ["URL['’]?s", "URLs"],
         ["ZWave", "Z-Wave"]
       ]

source/_cookbook/fail2ban.markdown

@@ -160,5 +160,5 @@ Fail2ban should now be configured and running, if an IP address is banned you wi
 
 If you want to read more about `fail2ban`, some links are below:
 
- - [fail2ban Split config](http://www.fail2ban.org/wiki/index.php/FEATURE_Split_config)
+ - [fail2ban Split configuration](http://www.fail2ban.org/wiki/index.php/FEATURE_Split_config)
  - [How To Protect SSH with Fail2Ban on Ubuntu 14.04](https://www.digitalocean.com/community/tutorials/how-to-protect-ssh-with-fail2ban-on-ubuntu-14-04)

source/_cookbook/ifttt.manything.markdown

@@ -7,7 +7,7 @@ redirect_from:
   /integrations/ifttt.manything/
 ---
 
-[Manything](https://manything.com) is a smart app that turns your Android device, iPhone, iPod, or iPad into a WiFi camera for monitoring your home, your pets, anything! Comes with live streaming, motion activated alerts, cloud video recording, and more.
+[Manything](https://manything.com) is a smart app that turns your Android device, iPhone, iPod, or iPad into a Wi-Fi camera for monitoring your home, your pets, anything! Comes with live streaming, motion activated alerts, cloud video recording, and more.
 
 To get manything support, HA will use IFTTT's [Webhooks Service](https://ifttt.com/maker_webhooks) and the [ManyThing Service](https://ifttt.com/manything). Use the [IFTTT Setup instructions](/integrations/ifttt/) to activate the IFTTT Platform.
 

source/_cookbook/owntracks_two_mqtt_broker.markdown

@@ -40,7 +40,7 @@ $ docker run -ti -p 1884:1883  \
     --name mosquitto-ext -d toke/mosquitto
 ```
 
-Here are the config files:
+Here are the configuration files:
 
 `/volume1/data/mosquitto-int/config/mosquitto.conf`
 

source/_docs/authentication/multi-factor-auth.markdown

@@ -33,7 +33,7 @@ homeassistant:
     - type: totp
 ```
 
-If no `auth_mfa_modules` config section is defined in `configuration.yaml` a TOTP module named "Authenticator app" will be autoloaded.
+If no `auth_mfa_modules` configuration section is defined in `configuration.yaml` a TOTP module named "Authenticator app" will be autoloaded.
 
 You will need an authenticator app on your phone. We recommend either [Google Authenticator](https://support.google.com/accounts/answer/1066447) or [Authy](https://authy.com/). Both are available for iOS or Android.
 

source/_docs/automation/troubleshooting.markdown

@@ -28,7 +28,7 @@ Please note that if you click on **Trigger** of an automation in the frontend, *
 All this makes that Trigger feature pretty limited and nearly useless for debugging purposes so you need to find another way.
 Make sure you check and adapt to your circumstances appropriate examples from Automation Trigger, Conditions and Actions.
 
-It is also useful to go to **Configuration** -> **Server Control** and click on **Check Config** button in Configuration validation section to make sure there are no syntax errors before restarting Home Assistant. In order for **Check Config** to be visible, you must enable **Advanced Mode** on your user profile.
+It is also useful to go to **Configuration** -> **Server Control** and click on **Check Configuration** button in Configuration validation section to make sure there are no syntax errors before restarting Home Assistant. In order for **Check configuration** to be visible, you must enable **Advanced Mode** on your user profile.
 
 If your automation uses templates in any part, you can do the following to make sure it works as expected:
 

source/_docs/autostart/upstart.markdown

@@ -128,4 +128,4 @@ sudo service hass-daemon stop
 
 When running Home Assistant with this script, the configuration directory will be located at `/var/opt/homeassistant`. This directory will contain a verbose log rather than simply an error log.
 
-When running daemons, it is good practice to have the daemon run under its own user name rather than the default user's name. Instructions for setting this up are outside the scope of this document.
+When running daemons, it is good practice to have the daemon run under its own username rather than the default user's name. Instructions for setting this up are outside the scope of this document.

source/_docs/configuration/packages.markdown

@@ -6,7 +6,7 @@ redirect_from: /topics/packages/
 
 Packages in Home Assistant provide a way to bundle different component's configuration together. We already learned about the two configuration styles (specifying platforms entries together or individually) on the [adding devices](/docs/configuration/devices/) page. Both of these configuration methods require you to create the integration key in the main `configuration.yaml` file. With packages we have a way to include different components, or different configuration parts using any of the `!include` directives introduced in [splitting the configuration](/docs/configuration/splitting_configuration).
 
-Packages are configured under the core `homeassistant/packages` in the configuration and take the format of a package name (no spaces, all lower case) followed by a dictionary with the package config. For example, package `pack_1` would be created as:
+Packages are configured under the core `homeassistant/packages` in the configuration and take the format of a package name (no spaces, all lower case) followed by a dictionary with the package configuration. For example, package `pack_1` would be created as:
 
 ```yaml
 homeassistant:
@@ -60,7 +60,7 @@ There are some rules for packages that will be merged:
 1. Platform based integrations (`light`, `switch`, etc) can always be merged.
 2. Components where entities are identified by a key that will represent the entity_id (`{key: config}`) need to have unique 'keys' between packages and the main configuration file. 
 
-    For example if we have the following in the main config. You are not allowed to re-use "my_input" again for `input_boolean` in a package:
+    For example if we have the following in the main configuration. You are not allowed to re-use "my_input" again for `input_boolean` in a package:
 
     ```yaml
     input_boolean:

source/_docs/configuration/securing.markdown

@@ -21,7 +21,7 @@ If you want secure remote access, the easiest option is to use [Home Assistant c
 
 As well as the above we advise that you consider the following to improve security:
 
-- For systems that use SSH set `PermitRootLogin no` in your sshd config (usually `/etc/ssh/sshd_config`) and to use SSH keys for authentication instead of passwords. This is particularly important if you enable remote access to your SSH services.
+- For systems that use SSH set `PermitRootLogin no` in your sshd configuration (usually `/etc/ssh/sshd_config`) and to use SSH keys for authentication instead of passwords. This is particularly important if you enable remote access to your SSH services.
 - Lock down the host following good practice guidance, for example:
   * [Securing Debian Manual](https://www.debian.org/doc/manuals/securing-debian-howto/index.en.html) (this also applies to Raspbian)
   * [Red Hat Enterprise Linux 7 Security Guide](https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/pdf/Security_Guide/Red_Hat_Enterprise_Linux-7-Security_Guide-en-US.pdf), [CIS Red Hat Enterprise Linux 7 Benchmark](https://benchmarks.cisecurity.org/tools2/linux/CIS_Red_Hat_Enterprise_Linux_7_Benchmark_v1.0.0.pdf)

source/_docs/configuration/splitting_configuration.markdown

@@ -154,8 +154,8 @@ If you have issues checkout `home-assistant.log` in the configuration directory
 If you have many configuration files, the `check_config` script allows you to see how Home Assistant interprets them:
 
 - Listing all loaded files: `hass --script check_config --files`
-- Viewing a component's config: `hass --script check_config --info light`
-- Or all components' config:  `hass --script check_config --info all`
+- Viewing a component's configuration: `hass --script check_config --info light`
+- Or all components' configuration:  `hass --script check_config --info all`
 
 You can get help from the command line using: `hass --script check_config --help`
 

source/_docs/configuration/templating.markdown

@@ -186,7 +186,7 @@ Note: [UNIX timestamp](https://en.wikipedia.org/wiki/Unix_time) is the number of
 
 ### To/From JSON
 
-The `to_json` filter serializes an object to a JSON string. In some cases, it may be necessary to format a JSON string for use with a webhook, as a parameter for command line utilities or any number of other applications. This can be complicated in a template, especially when dealing with escaping special characters. Using the `to_json` filter, this is handled automatically.
+The `to_json` filter serializes an object to a JSON string. In some cases, it may be necessary to format a JSON string for use with a webhook, as a parameter for command-line utilities or any number of other applications. This can be complicated in a template, especially when dealing with escaping special characters. Using the `to_json` filter, this is handled automatically.
 
 The `from_json` filter operates similarly, but in the other direction, de-serializing a JSON string back into an object.
 

source/_docs/ecosystem/appdaemon.markdown

@@ -12,7 +12,7 @@ AppDaemon is not meant to replace Home Assistant Automations and Scripts, rather
 
 - New paradigm - Some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that automations can't.
 - Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible; experienced Python programmers should feel right at home.
-- Reuse - write a piece of code once and instantiate it as an App as many times as you need with different parameters; e.g., a motion light program that you can use in five different places around your home. The code stays the same, you just dynamically add new instances of it in the config file.
+- Reuse - write a piece of code once and instantiate it as an App as many times as you need with different parameters; e.g., a motion light program that you can use in five different places around your home. The code stays the same, you just dynamically add new instances of it in the configuration file.
 - Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it, and restart them to use the new code without the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple Apps and have them picked up dynamically. For a final trick, removing or adding Apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
 - Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic.
 - Durable variables and state - Variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened.

source/_docs/ecosystem/appdaemon/api.markdown

@@ -18,7 +18,7 @@ class MotionLights(appapi.AppDaemon):
     """Motion lights implementation."""
 ```
 
-When configured as an app in the config file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to its `initialize()` function - this function must appear as part of every app:
+When configured as an app in the configuration file (more on that later) the lifecycle of the App begins. It will be instantiated as an object by AppDaemon, and immediately, it will have a call made to its `initialize()` function - this function must appear as part of every app:
 
 ```python
   def initialize(self):
@@ -1936,7 +1936,7 @@ get_app(self, name)
 
 ##### name
 
-Name of the app required. This is the name specified in header section of the config file, not the module or class.
+Name of the app required. This is the name specified in header section of the configuration file, not the module or class.
 
 #### Returns
 
@@ -2035,19 +2035,19 @@ self.error("Some Critical string", level="CRITICAL")
 
 Sharing information between different Apps is very simple if required. Each app gets access to a global dictionary stored in a class attribute called `self.global_vars`. Any App can add or read any key as required. This operation is not however threadsafe so some car is needed.
 
-In addition, Apps have access to the entire configuration if required, meaning they can access AppDaemon configuration items as well as parameters from other Apps. To use this, there is a class attribute called `self.config`. It contains a `ConfigParser` object, which is similar in operation to a `Dictionary`. To access any apps parameters, simply reference the ConfigParser object using the Apps name (form the config file) as the first key, and the parameter required as the second, for instance:
+In addition, Apps have access to the entire configuration if required, meaning they can access AppDaemon configuration items as well as parameters from other Apps. To use this, there is a class attribute called `self.config`. It contains a `ConfigParser` object, which is similar in operation to a `Dictionary`. To access any apps parameters, simply reference the ConfigParser object using the Apps name (form the configuration file) as the first key, and the parameter required as the second, for instance:
 
 ```python
 other_apps_arg = self.config["some_app"]["some_parameter"]
 ```
 
-To get AppDaemon's config parameters, use the key "AppDaemon", e.g.:
+To get AppDaemon's configuration parameters, use the key "AppDaemon", e.g.:
 
 ```python
 app_timezone = self.config["AppDaemon"]["time_zone"]
 ```
 
-And finally, it is also possible to use the AppDaemon as a global area for sharing parameters across Apps. Simply add the required parameters to the AppDaemon section of your config:
+And finally, it is also possible to use the AppDaemon as a global area for sharing parameters across Apps. Simply add the required parameters to the AppDaemon section of your configuration:
 
 ```ini
 [AppDaemon]

source/_docs/ecosystem/appdaemon/running.markdown

@@ -8,7 +8,7 @@ As configured, `AppDaemon` comes with a single HelloWorld App that will send a g
 
 ## Docker
 
-Assuming you have set the config up as described above for Docker, you can run it with the command:
+Assuming you have set the configuration up as described above for Docker, you can run it with the command:
 
 ```bash
 $ docker run -d -v <Path to Config>/conf:/conf --name appdaemon acockburn/appdaemon:latest

source/_docs/ecosystem/appdaemon/tutorial.markdown

@@ -23,7 +23,7 @@ So why `AppDaemon`? AppDaemon is not meant to replace Home Assistant Automations
 
 - New paradigm - some problems require a procedural and/or iterative approach, and `AppDaemon` Apps are a much more natural fit for this. Recent enhancements to Home Assistant scripts and templates have made huge strides, but for the most complex scenarios, Apps can do things that Automations can't
 - Ease of use - AppDaemon's API is full of helper functions that make programming as easy and natural as possible. The functions and their operation are as "Pythonic" as possible, experienced Python programmers should feel right at home.
-- Reuse - write a piece of code once and instantiate it as an app as many times as you need with different parameters e.g., a motion light program that you can use in 5 different places around your home. The code stays the same, you just dynamically add new instances of it in the config file
+- Reuse - write a piece of code once and instantiate it as an app as many times as you need with different parameters e.g., a motion light program that you can use in 5 different places around your home. The code stays the same, you just dynamically add new instances of it in the configuration file
 - Dynamic - AppDaemon has been designed from the start to enable the user to make changes without requiring a restart of Home Assistant, thanks to its loose coupling. However, it is better than that - the user can make changes to code and AppDaemon will automatically reload the code, figure out which Apps were using it and restart them to use the new code with out the need to restart `AppDaemon` itself. It is also possible to change parameters for an individual or multiple apps and have them picked up dynamically, and for a final trick, removing or adding apps is also picked up dynamically. Testing cycles become a lot more efficient as a result.
 - Complex logic - Python's If/Else constructs are clearer and easier to code for arbitrarily complex nested logic
 - Durable variables and state - variables can be kept between events to keep track of things like the number of times a motion sensor has been activated, or how long it has been since a door opened

source/_docs/ecosystem/haproxy.markdown

@@ -86,7 +86,7 @@ Forward ports 443 and (optionally) 80 to your server on your router.
 Do not forward port 8123, HAProxy takes care of securing the connection with HTTPS on 443.
 If 8123 is forwarded then it will not be secured.
 
-Replace 443 with whatever port you chose to bind to in the config if different.
+Replace 443 with whatever port you chose to bind to in the configuration if different.
 
 ### Configure Home Assistant HTTP Component
 

source/_docs/ecosystem/nginx.markdown

@@ -97,7 +97,7 @@ http:
   trusted_proxies: <NGINX IP address here, or 127.0.0.1 if hosted on the same machine>
 ```
 
-### NGINX Config
+### NGINX configuration
 
 ```nginx
 map $http_upgrade $connection_upgrade {