rephrase

source/_integrations/mqtt.markdown

@@ -629,7 +629,7 @@ For more examples [see](/integrations/mqtt/#discovery-examples-with-component-di
 
 The payload must be a serialized JSON dictionary and will be checked like an entry in your {% term "`configuration.yaml`" %} file if a new device is added, with the exception that unknown configuration keys are allowed but ignored. This means that missing variables will be filled with the integration's default values. All configuration variables which are *required* must be present in the payload. The reason for allowing unknown documentation keys is allow some backwards compatibility, software generating MQTT discovery messages can then be used with older Home Assistant versions which will simply ignore new features.
 
-A discovery payload could be sent with a retain flag set. In that case, the discovery message will be stored at the MQTT broker, and will be processed automatically when the MQTT integrations starts up. This removes the need for it to be resent. A better approach thought, is that the software generating MQTT discovery messages, sends discovery payload(s), when the MQTT integration sends the [Birth message](#birth-and-last-will-messages).
+A discovery payload can be sent with a retain flag set. In that case, the discovery message will be stored at the MQTT broker, and will be processed automatically when the MQTT integrations starts up. This removes the need for it to be resent. A better approach thought, is that the software generating MQTT discovery messages, sends discovery payload(s), when the MQTT integration sends the [Birth message](#birth-and-last-will-messages).
 
 Subsequent messages on a topic where a valid payload has been received will be handled as a configuration update, and a configuration update with an empty payload will cause a previously discovered device to be deleted.