Replace all abstract usages of his/he/her with they/their/it.

3 files changed, 3 insertions, 3 deletions

diff --git a/src/modules/extra/m_mysql.cpp b/src/modules/extra/m_mysql.cpp
index 4f727519f..6a9f38b6c 100644
--- a/src/modules/extra/m_mysql.cpp
+++ b/src/modules/extra/m_mysql.cpp
@@ -68,7 +68,7 @@
  * The ircd thread then mutexes the queue once more, reads the outbound response off the head
  * of the queue, and sends it on its way to the original calling module.
  *
- * XXX: You might be asking "why doesnt he just send the response from within the worker thread?"
+ * XXX: You might be asking "why doesnt it just send the response from within the worker thread?"
  * The answer to this is simple. The majority of InspIRCd, and in fact most ircd's are not
  * threadsafe. This module is designed to be threadsafe and is careful with its use of threads,
  * however, if we were to call a module's OnRequest even from within a thread which was not the
diff --git a/src/modules/m_delayjoin.cpp b/src/modules/m_delayjoin.cpp
index acfbfce26..1c1d36e19 100644
--- a/src/modules/m_delayjoin.cpp
+++ b/src/modules/m_delayjoin.cpp
@@ -215,7 +215,7 @@ void DelayJoinMode::RevealUser(User* user, Channel* chan)
 	chan->Write(joinevent, 0, except_list);
 }
 
-/* make the user visible if he receives any mode change */
+/* make the user visible if they receive any mode change */
 ModResult ModuleDelayJoin::OnRawMode(User* user, Channel* channel, ModeHandler* mh, const std::string& param, bool adding)
 {
 	if (!channel || param.empty())
diff --git a/src/modules/m_spanningtree/svsnick.cpp b/src/modules/m_spanningtree/svsnick.cpp
index a734dc8ed..c44a6a4bb 100644
--- a/src/modules/m_spanningtree/svsnick.cpp
+++ b/src/modules/m_spanningtree/svsnick.cpp
@@ -41,7 +41,7 @@ CmdResult CommandSVSNick::Handle(User* user, Params& parameters)
 		// 4. SVSNICK arrives
 		// 5. Attila_ gets his nick changed to Guest12345 unnecessarily
 		//
-		// In this case when the SVSNICK is processed the target has already changed his nick to something
+		// In this case when the SVSNICK is processed the target has already changed their nick to something
 		// which isn't protected, so changing the nick again to a Guest nick is not desired.
 		// However, if the expected nick TS parameter is present in the SVSNICK then the nick change in step 5
 		// won't happen because the timestamps won't match.