Index: main/waeup.kofa/trunk/docs/source/userdocs/academics.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/academics.rst	(revision 13076)
+++ main/waeup.kofa/trunk/docs/source/userdocs/academics.rst	(revision 13078)
@@ -128,4 +128,5 @@
    :noindex:
 
+.. _certificate:
 
 Certificate
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13076)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants.rst	(revision 13078)
@@ -1,14 +1,86 @@
 .. _applicants_section:
 
-Applicants Section :sup:`in progress`
-*************************************
+Applicants Section
+******************
 
-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.
+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.
+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.
 
 .. note::
 
-  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.
+  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
+Much like students, applicants are also a users of the portal and
+the applicant object is a user account surrogate, see
+:ref:`Applicants and Students <applicants_and_students>`. In the
+following we always refer to the applicant container when talking
+about an applicant.
+
+In contrast to students containers, applicant containers do not
+contain subcontainers. The only objects they contain are applicant
+payment tickets (i.e. instances of `ApplicantOnlinePayment`). Thus
+the hierarchy is flat and not really treelike as the students
+section. Also, applicants (applicant containers) are stored in
+different parent containers (instances of `IApplicantsContainer`).
+There is not one single parent container like in the students
+section but one container for each application session and
+application type::
+
+  Applicants Section (ApplicantsRoot)
+  |
+  +---> ApplicantsContainer
+        |
+        +---> Applicant
+              |
+              +-----> ApplicantOnlinePayment
+
+
+Interfaces
+==========
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/interfaces
+
+Workflow & History
+==================
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/workflow
+
+Browser Pages
+=============
+
+.. toctree::
+   :maxdepth: 3
+
+   applicants/browser
+
+
+
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst	(revision 13078)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants/browser.rst	(revision 13078)
@@ -0,0 +1,4 @@
+.. _applicants_browser:
+
+Browsing the Applicants Section :sup:`in progress`
+==================================================
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst	(revision 13078)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants/interfaces.rst	(revision 13078)
@@ -0,0 +1,77 @@
+.. _applicants_interfaces:
+
+Parent Containers
+=================
+
+`IApplicantsRoot`
+-----------------
+
+Much like ``academics`` and ``students``, also ``applicants`` is a
+unique container (of type `ApplicantsRoot`) located in the
+`IUniversity` instance. It is the counterpart of the students
+(section) container. The root container has a `description` schema
+field attribute which contains human readable, multi-lingual
+information about the application procedure in HTML format. This
+description can be seen by anonymous users, when they enter the
+applicants section (by pressing the 'Application' tab in the
+navigation bar).
+
+.. _multilingual:
+
+.. note::
+
+  A multi-lingual or localized text is a sequence of human-readable
+  text strings in different languages. The languages must be separated
+  by ``>>xy<<``, whereas ``xy`` is the language code. Text parts
+  without correct leading language separator - usually the first part
+  has no language descriptor - are interpreted as texts in the
+  portal's language. The text strings can be either HTML or
+  reStructuredText (REST) formatted.
+
+.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
+   :pyobject: IApplicantsRoot
+
+`IApplicantsContainer`
+----------------------
+
+The applicants root contains the various `ApplicantsContainer`
+objects. It's worth to present their interface here.
+
+.. literalinclude:: ../../../../src/waeup/kofa/applicants/interfaces.py
+   :pyobject: IApplicantsContainer
+
+`statistics` and `expired` are read-only property attributes.
+`description_dict` contains the same information as the
+`description`, but the sequence of language translations has been
+split up and copied into a dictionary for faster processing. In the
+base package, `local_roles` is an empty list which means, no local
+role can be assigned at applicants container level.
+
+Crucial for application are the `prefix`, `year`, `mode` and
+`application_category` schema fields. The `prefix` atribute can only
+be set when adding a container. It cannot be edited afterwards. The
+attribute determines the application type and automatically sets the
+prefix of the container code and of all applicant ids inside the
+container. The prefix is supplied by the `ApplicationTypeSource`
+(see `application types of base package
+<https://kofa-demo.waeup.org/sources#collapseAppTypes>`_). It is
+followed by the year of entry. Thus, the identifiers of applicants
+containers and the applicants inside the containers start with the
+same prefix-year sequence. Example: ``app2015`` which translates
+into 'General Studies 2015/2016'. Consequently, **applicants cannot
+be moved from one container to another.**
+
+The application category is supplied by the
+`ApplicationCategorySource` (see `application categories of base
+package <https://kofa-demo.waeup.org/sources#collapseAppCats>`_) and
+refers to a group of study programmes (certificates) which the
+applicant can apply for, read also chapter on :ref:`Certificates
+<certificate>`.
+
+Applicant :sup:`in progress`
+============================
+
+`IApplicantBaseData`
+--------------------
+
+
Index: main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst	(revision 13078)
+++ main/waeup.kofa/trunk/docs/source/userdocs/applicants/workflow.rst	(revision 13078)
@@ -0,0 +1,4 @@
+.. _application_workflow:
+
+Application Workflow :sup:`in progress`
+=======================================
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13076)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/browser.rst	(revision 13078)
@@ -16,4 +16,12 @@
 described above.
 
+.. _navigation_bar:
+
+Navigation Bar
+==============
+
+
+
+
 
 .. _page_layout:
@@ -26,5 +34,5 @@
 only a static top navigation bar. Students can navigate to the
 various display form pages of their record by pulling down the 'My
-Data' in the navigation bar.
+Data' tab in the navigation bar.
 
 Officers see a double-column theme after logging in. The left column
Index: main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst
===================================================================
--- main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 13076)
+++ main/waeup.kofa/trunk/docs/source/userdocs/students/interfaces.rst	(revision 13078)
@@ -1,3 +1,3 @@
-.. _interfaces:
+.. _students_interfaces:
 
 Student
