Bunch of comment typo fixes

[ci skip]

src/gui/widgets/scrollbar_container.hpp

@@ -99,7 +99,7 @@ class scrollbar_container : public container_base
 	/**
 	 * See @ref widget::can_wrap.
 	 *
-	 * @note This function is called before the object is finalised.
+	 * @note This function is called before the object is finalized.
 	 */
 	virtual bool can_wrap() const override;
 
@@ -162,7 +162,7 @@ class scrollbar_container : public container_base
 	{
 		return content_grid_;
 	}
-	
+
 	const grid* content_grid() const
 	{
 		return content_grid_;
@@ -316,11 +316,11 @@ class scrollbar_container : public container_base
 	 *                            * positive values increase height.
 	 * @param width_modification_pos
 	 *                            The position where the additional content was
-	 *                            inserted/removed, defaults to -1 whcih means
+	 *                            inserted/removed, defaults to -1 which means
 	 *                            'at end'
 	 * @param height_modification_pos
 	 *                            The position where the additional content was
-	 *                            inserted/removed, defaults to -1 whcih means
+	 *                            inserted/removed, defaults to -1 which means
 	 *                            'at end'
 	 *
 	 * @returns                   True is wanted modification is accepted false

src/gui/widgets/window.cpp

@@ -623,7 +623,7 @@ int window::show(const bool restore, const unsigned auto_close_timeout)
 
 			if(!mouse_button_state_initialized) {
 				/*
-				 * The state must be initialize when showing the dialogue.
+				 * The state must be initialize when showing the dialog.
 				 * However when initialized before this point there were random
 				 * errors. This only happened when the 'click' was done fast; a
 				 * slower click worked properly.

src/gui/widgets/window.hpp

@@ -644,7 +644,7 @@ class window : public panel, public cursor::setter
 	void layout_linked_widgets();
 
 	/**
-	 * Handles a mouse click event for dismissing the dialogue.
+	 * Handles a mouse click event for dismissing the dialog.
 	 *
 	 * @param mouse_button_mask   The SDL_BUTTON mask for the button used to
 	 *                            dismiss the click. If the caller is from the
@@ -658,16 +658,16 @@ class window : public panel, public cursor::setter
 	/**
 	 * The state of the mouse button.
 	 *
-	 * When click dismissing a dialogue in the past the DOWN event was used.
+	 * When click dismissing a dialog in the past the DOWN event was used.
 	 * This lead to a bug [1]. The obvious change was to switch to the UP
-	 * event, this lead to another bug; the dialogue was directly dismissed.
+	 * event, this lead to another bug; the dialog was directly dismissed.
 	 * Since the game map code uses the UP and DOWN event to select a unit
 	 * there is no simple solution.
 	 *
 	 * Upon entry this value stores the mouse button state at entry. When a
 	 * button is DOWN and goes UP that button does \em not trigger a dismissal
-	 * of the dialogue, instead that button's down state is removed from this
-	 * variable. Therefore the next UP event does dismiss the dialogue.
+	 * of the dialog, instead that button's down state is removed from this
+	 * variable. Therefore the next UP event does dismiss the dialog.
 	 *
 	 * [1] https://gna.org/bugs/index.php?18970
 	 */

src/scripting/lua_cpp_function.hpp

@@ -69,7 +69,7 @@
  * manager object etc. etc.
  *
  * Circa 2012, the solution was to implement every callback function in the wesnoth
- * table simply as a C function, whcih grabs whatever engine features it needs from
+ * table simply as a C function, which grabs whatever engine features it needs from
  * a collection of pointers with external linkage in resources.hpp. The pointers
  * must be reset by the play controller object whenver it is created or destroyed...
  * or reset (replay controller), and always in a particular order because eventually

src/sdl/window.hpp

@@ -33,7 +33,7 @@ namespace sdl
  * The wrapper class for the @ref SDL_Window class.
  *
  * At the moment of writing it is not certain yet how many windows will be
- * created. At least one as main window, but maybe the GUI dialogues will have
+ * created. At least one as main window, but maybe the GUI dialogs will have
  * their own window. Once that is known it might be a good idea to evaluate
  * whether the class should become a singleton or not.
  *