3 files changed, 7 insertions, 7 deletions

diff --git a/doc/artsbuilder/artsbuilder.docbook b/doc/artsbuilder/artsbuilder.docbook
index b5f4f68c..63e39e0b 100644
--- a/doc/artsbuilder/artsbuilder.docbook
+++ b/doc/artsbuilder/artsbuilder.docbook
@@ -339,7 +339,7 @@ Finally, you can delete the Synth_SEQUENCE module, and rather
 connect connect the frequency input port of the structure to the
 Synth_FREQUENCY frequency port. Hm. But what do do about
 pos?</para> <para>We don't have this, because with no algorithm in the
-world, you can predict when the user will release the note he just
+world, you can predict when the user will release the note they just
 pressed on the midi keyboard. So we rather have a pressed parameter
 instead that just indicates wether the user still holds down the
 key. (pressed = 1: key still hold down, pressed = 0: key
diff --git a/doc/artsbuilder/detail.docbook b/doc/artsbuilder/detail.docbook
index c7ed7319..34adf3d1 100644
--- a/doc/artsbuilder/detail.docbook
+++ b/doc/artsbuilder/detail.docbook
@@ -1662,8 +1662,8 @@ objects that are send over wire are tagged before transfer.
 </para>
 
 <para>
-If the receiver receives an object which is on his server, of course he
-will not <function>_useRemote()</function> it. For this special case,
+If the receiver receives an object which is on their server, of course
+they will not <function>_useRemote()</function> it. For this special case,
 <function>_cancelCopyRemote()</function> exists to remove the tag
 manually. Other than that, there is also timer based tag removal, if
 tagging was done, but the receiver didn't really get the object (due to
diff --git a/doc/artsbuilder/mcop.docbook b/doc/artsbuilder/mcop.docbook
index 59d9a011..4b1d6615 100644
--- a/doc/artsbuilder/mcop.docbook
+++ b/doc/artsbuilder/mcop.docbook
@@ -1476,7 +1476,7 @@ Marshalling should be easy to implement.
 
 <listitem>
 <para>
-Demarshalling requires the receiver to know what type he wants to
+Demarshalling requires the receiver to know what type they want to
 demarshall.
 </para>
 </listitem>
@@ -2200,9 +2200,9 @@ it is used in daily &kde; usage: people send types like
 <classname>QString</classname>, <classname>QRect</classname>,
 <classname>QPixmap</classname>, <classname>QCString</classname>, ...,
 around. These use &Qt;-serialization. So if somebody choose to support
-&DCOP; in a GNOME program, he would either have to claim to use
-<classname>QString</classname>,...  types (although he doesn't do so),
-and emulate the way &Qt; does the streaming, or he would send other
+&DCOP; in a GNOME program, they would either have to claim to use
+<classname>QString</classname>,...  types (although they don't do so),
+and emulate the way &Qt; does the streaming, or they would send other
 string, pixmap and rect types around, and thus not be interoperable.
 </para>