Index: openacs-4/packages/acs-core-docs/www/xml/kernel/ext-auth.xml
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/xml/kernel/ext-auth.xml,v
diff -u -r1.7 -r1.8
--- openacs-4/packages/acs-core-docs/www/xml/kernel/ext-auth.xml	28 Mar 2018 21:55:34 -0000	1.7
+++ openacs-4/packages/acs-core-docs/www/xml/kernel/ext-auth.xml	25 Apr 2018 08:38:28 -0000	1.8
@@ -167,7 +167,7 @@
 either already be in the users table through a batch
 synchronization job, or that the relevant authentication
 implementation supports real-time synchronization of user data.
-Specifically, if you want remote users who haven't yet logged in to
+Specifically, if you want remote users who haven't yet logged-in to
 OpenACS to show up in user searches, you'll have to do the batch
 synchronization.</para>
       <para>All in all, the login box will be an includeable template and
@@ -511,19 +511,19 @@
       </segmentedlist>
       <para>I like the idea of having multiple login levels:</para>
       <orderedlist>
-        <listitem><para>Not logged in</para></listitem>
+        <listitem><para>Not logged-in</para></listitem>
         <listitem><para>Untrusted login: We&#39;ll show you un-sensitive personal
           content, but won&#39;t let you modify anything or see personal data. A
           normal login becomes untrusted after a certain amount of time, and
           the user will have to re-enter his/her password in order to gain
           access to personal data. Untrusted login never expires, unless
           explicitly done so through either changing password or clicking a
           special "expire all logins" link.</para></listitem>
-        <listitem><para>Normal login: The user is logged, and has type his
+        <listitem><para>Normal login: The user is logged-in, and has type his
           password sufficiently recently that we trust the login. All normal
           operations are allowed. Will degrade to untrusted login after a
           specified amount of time.</para></listitem>
-        <listitem><para>Secure login: The user is logged in over a secure
+        <listitem><para>Secure login: The user is logged-in over a secure
           connection (HTTPS), potentially even using a special secure
           password. This would be for sensitive actions, such as credit card
           transactions.</para></listitem>
@@ -544,13 +544,13 @@
 even more feasible to have a more secure login expiration
 setting.</para>
       <para>By default, <literal>auth::require_login</literal> would
-bounce to the login page if the user is only logged in at the
+bounce to the login page if the user is only logged-in at the
 untrusted level. Only if you explicitly say
 <literal>auth::require_login -untrusted</literal> will we give you
-the user_id of a user who&#39;s only logged in in untrusted
+the user_id of a user who&#39;s only logged-in in untrusted
 mode.</para>
       <para>Similarly, <literal>ad_conn user_id</literal> will continue
-to return 0 (not logged in) when the user is only logged in
+to return 0 (not logged-in) when the user is only logged-in
 untrusted, and we&#39;ll supply another variable, <literal>ad_conn
 untrusted_user_id</literal>, which wlll be set to the user_id for
 all login levels.</para>
@@ -619,10 +619,10 @@
           </seglistitem>
       </segmentedlist>
       <para>Currently, if you&#39;ve ever left a permanent login cookie on
-someone elses machine, that person will be forever logged in until
+someone elses machine, that person will be forever logged-in until
 he/she explicitly logs out. You can change your password, you can
 do anything you want, but unless a logout is requested from that
-particular browser, that browser will be logged in forever.</para>
+particular browser, that browser will be logged-in forever.</para>
       <para>I want to change our session handling code so that old login
 cookies can be expired. This would be done automatically whenever
 you change your password, and we could also offer a link which does