Spell check pluginAPI

diff --git a/docs/manuals/en/developers/pluginAPI.tex b/docs/manuals/en/developers/pluginAPI.tex
index 4856a5dd4332c797154b4d07e24e9968da0f0ec4..386aad18e933ba6083c365c2b0216482cfbb9676 100644 (file)
--- a/docs/manuals/en/developers/pluginAPI.tex
+++ b/docs/manuals/en/developers/pluginAPI.tex
@@ -16,7 +16,7 @@ similar to how a {\bf RunScript} works, and the events are very similar.  Once
 the plugin gets control, it can interact with Bacula by getting and setting
 Bacula variables.  In this way, it behaves much like a RunScript.  Currently
 very few Bacula variables are defined, but they will be implemented as the need
-arrises, and it is very extensible.
+arises, and it is very extensible.
 
 We plan to have plugins register to receive events that they normally would
 not receive, such as an event for each file examined for backup or restore.
@@ -75,7 +75,7 @@ bRC unloadPlugin()
 
 both these external entry points to the shared object are defined as C entry
 points to avoid name mangling complications with C++.  However, the shared
-object can actually be written in any language (preferrably C or C++) providing
+object can actually be written in any language (preferably C or C++) providing
 that it follows C language calling conventions.
 
 The definitions for {\bf bRC} and the arguments are {\bf
@@ -94,7 +94,7 @@ files:
 
 Aside from the {\bf bc\_types.h} and {\bf confit.h} headers, the plugin
 definition uses the minimum code from Bacula.  The bc\_types.h file is required
-to ensure that the data type defintions in arguments correspond to the Bacula
+to ensure that the data type definitions in arguments correspond to the Bacula
 core code.
 
 The return codes are defined as:
@@ -299,13 +299,13 @@ loadPlugin() externally defined entry point.
   (malloc the memory) and store a pointer to
   its private working storage in the {\bf pContext} variable.
   Note: since Bacula is a multi-threaded program, you must not
-  keep any variable data in your plugin unless it is truely meant
+  keep any variable data in your plugin unless it is truly meant
   to apply globally to the whole plugin.  In addition, you must
   be aware that except the first and last call to the plugin
   (loadPlugin and unloadPlugin) all the other calls will be 
   made by threads that correspond to a Bacula job.  The 
   bpContext that will be passed for each thread will remain the
-  same throughout the Job thus you can keep your privat Job specific
+  same throughout the Job thus you can keep your private Job specific
   data in it ({\bf bContext}).
 
 \begin{verbatim}
@@ -868,4 +868,3 @@ a real plugin, which is still rather simple and small.
 
 When actually writing your own plugin, you may use the example-plugin-fd.c
 code as a template for your code.
-