Index: main/waeup.kofa/trunk/docs/source/developerdocs/api/api_students.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/developerdocs/api/api_students.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/developerdocs/api/api_students.rst	(revision 13076)
@@ -1,4 +1,4 @@
-`students` -- Student Section Components Package
-************************************************
+`students` -- Students Section Components Package
+*************************************************
 
 (see also: :ref:`api-students-modules`)
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13076)
@@ -1,8 +1,8 @@
-.. _applicant_section:
+.. _applicants_section:
 
-Applicant Section :sup:`in progress`
-************************************
+Applicants Section :sup:`in progress`
+*************************************
 
-Applicants and Students are different entities. Moreover, the student section is completely independent from the applicant section. Kofa can be configured without its `applicants` module but not without its `students` module.
+Applicants and Students are different entities and stored in different places. Moreover, the students section is completely independent from the applicants section. Kofa can be configured without its `applicants` module but not without its `students` module.
 
 Anonymous users can self-register and automatically become applicants (users) of the portal. The number of applicants is not limited and, theoretically, Kofa can host hundredthousands of applicants in various applicants containers. Usually, only a few of them are beeing accepted for studying at the university. Once the application process has ended, admitted applicants are transformed into student records.  New student records are created and the data are copied from the applicant records. When this 'student creation' process is finished, the applicant records are dispensable. Aim was to provide an easy way to get rid of the huge batches of applicant records by only one click, in order to keep the database clean and tidy. The process is described further below.
@@ -10,3 +10,5 @@
 .. note::
 
-  The term 'application' has a double meaning in English. An 'application' in computer sciences is understood as a software or web application. Software developers may get confused by using the term in a different context. To take this into account, we prefer to speak of an 'applicant' in this documentation, instead of an 'application' although, in the linguistic context, it sometimes makes more sense to speak of the latter. However, in the user interface (UI) and also in Python docstrings the term 'application' predominates.
+  The term 'application' has a double meaning in English. An 'application' in computer sciences stands for a software or web application. Software developers may get confused by using the term in a different context. To take this into account, we prefer to speak of 'applicant' in this documentation, instead of 'application' although, in the linguistic context, it sometimes makes more sense to speak of the latter. However, in the user interface (UI) and also in Python docstrings the term 'application' predominates.
+
+In contrast to student containers, applicant containers do not contain subcontainers. The only objects they contain are applicant payment tickets (i.e. instances `ApplicantOnlinePayment`). Thus it does not make sense to speak of a  treelike structure. In contrast to the students section
Index: main/waeup.kofa/trunk/docs/source/userdocs/security.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/userdocs/security.rst	(revision 13076)
@@ -89,6 +89,6 @@
    :noindex:
 
-Applicant Section Permissions
------------------------------
+Applicants Section Permissions
+------------------------------
 
 .. autoclass:: waeup.kofa.applicants.permissions.ViewApplication()
@@ -107,6 +107,6 @@
    :noindex:
 
-Student Section Permissions
----------------------------
+Students Section Permissions
+----------------------------
 
 .. autoclass:: waeup.kofa.students.permissions.ViewStudent()
@@ -199,9 +199,9 @@
    :noindex:
 
-Global Applicant Section Roles
-------------------------------
-
-Global Applicant Section Roles are assigned portal-wide (globally)
-but do actually only allocate permissions in the applicant section.
+Global Applicants Section Roles
+-------------------------------
+
+Global Applicants Section Roles are assigned portal-wide (globally)
+but do actually only allocate permissions in the applicants section.
 
 .. autoclass:: waeup.kofa.applicants.permissions.ApplicantRole()
@@ -214,9 +214,9 @@
    :noindex:
 
-Global Student Section Roles
-----------------------------
-
-Global Student Section Roles are assigned portal-wide (globally) but
-do actually only allocate permissions in the student section.
+Global Students Section Roles
+-----------------------------
+
+Global Students Section Roles are assigned portal-wide (globally) but
+do actually only allocate permissions in the students section.
 
 .. autoclass:: waeup.kofa.students.permissions.StudentRole()
@@ -249,5 +249,5 @@
 strange that some of these 'odd' roles do not give more permissions
 than the user already has due to other roles. Their real purpose is to
-delegate permissions to the students or applicant section. If a user
+delegate permissions to the students or applicants section. If a user
 has for example the LocalStudentsManager role described below at
 department level, s/he automatically gets the StudentsManager role for
Index: main/waeup.kofa/trunk/docs/source/userdocs/students.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students.rst	(revision 13076)
@@ -1,6 +1,6 @@
 .. _student_section:
 
-Student Section
-***************
+Students Section
+****************
 
 'Student' is a multi-purpose term in Kofa which may lead to some
@@ -13,8 +13,8 @@
 
 The :ref:`treelike storage of objects <object_database>` in the
-student section can be figured as follows::
+students section can be figured as follows::
 
 
-  Student Section (StudentsContainer)
+  Students Section (StudentsContainer)
   |
   +---> Student
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13076)
@@ -1,6 +1,6 @@
 .. _students_browser:
 
-Browsing the Student Section
-============================
+Browsing the Students Section
+=============================
 
 The reader may ask: How do officers and students browse the portal?
@@ -376,5 +376,5 @@
 
 Lecturers cannot access student records directly. They don't have
-access to the student section. Instead, lecturers go to their course
+access to the students section. Instead, lecturers go to their course
 in the academic section and view or export lists of students who
 attended the course, either in a previous or in the current session.
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 13075)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 13076)
@@ -308,4 +308,7 @@
 -----------------------
 
+`IStudentOnlinePayment` instances are called student payment tickets
+or sometimes only payments. They contain the data which confirm that
+the student has paid a specific fee.
 `waeup.kofa.students.interfaces.IStudentOnlinePayment` inherits from
 `waeup.kofa.payments.interfaces.IOnlinePayment` and has only two
