Index: openacs-4/packages/acs-core-docs/www/i18n-introduction.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/i18n-introduction.html,v
diff -u -r1.20.2.1 -r1.20.2.2
--- openacs-4/packages/acs-core-docs/www/i18n-introduction.html	2 Mar 2019 19:30:04 -0000	1.20.2.1
+++ openacs-4/packages/acs-core-docs/www/i18n-introduction.html	3 Sep 2021 09:15:02 -0000	1.20.2.2
@@ -29,11 +29,11 @@
       keys and localized ADP files.  For ADP pages which are mostly
       code, replacing the message text with message key placeholders
       is simpler.  This approach also allows new translation in the
-      database, without affecting the file system.  For ADP pages
+      database, without affecting the filesystem.  For ADP pages
       which are static and mostly text, it may be easier to create a
       new ADP page for each language.  In this case, the pages are
       distinguished by a file naming convention.
-    </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-content"></a>User Content</h3></div></div></div><p>OpenACS does not have a general system for supporting multiple, localized versions of user-input content.  This document currently refers only to internationalizing the text in the package user interface.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-locale-templates"></a>Separate Templates for each Locale</h3></div></div></div><p>If the request processor finds a file named <code class="computeroutput">filename.locale.adp</code>, where locale matches the user's locale, it will process that file instead of <code class="computeroutput">filename.adp</code>.  For example, for a user with locale <code class="computeroutput">tl_PH</code>, the file <code class="computeroutput">index.tl_PH.adp</code>, if found, will be used instead of <code class="computeroutput">index.adp</code>.  The locale-specific file should thus contain text in the language appropriate for that locale.  The code in the page, however, should still be in English.  Message keys are processed normally.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-message-catalog"></a>Message Catalogs</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="i18n-message-catalog-adps"></a>Message Keys in Template Files (ADP Files)</h4></div></div></div><p>
+    </p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-content"></a>User Content</h3></div></div></div><p>OpenACS does not have a general system for supporting multiple, localized versions of user-input content.  This document currently refers only to internationalizing the text in the package user interface.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-locale-templates"></a>Separate Templates for each Locale</h3></div></div></div><p>If the request processor finds a filenamed <code class="computeroutput">filename.locale.adp</code>, where locale matches the user's locale, it will process that file instead of <code class="computeroutput">filename.adp</code>.  For example, for a user with locale <code class="computeroutput">tl_PH</code>, the file <code class="computeroutput">index.tl_PH.adp</code>, if found, will be used instead of <code class="computeroutput">index.adp</code>.  The locale-specific file should thus contain text in the language appropriate for that locale.  The code in the page, however, should still be in English.  Message keys are processed normally.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a name="i18n-message-catalog"></a>Message Catalogs</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a name="i18n-message-catalog-adps"></a>Message Keys in Template Files (ADP Files)</h4></div></div></div><p>
         Internationalizing templates is about replacing human readable
         text in a certain language with internal message keys, which
         can then be dynamically replaced with real human language in
@@ -89,7 +89,7 @@
         files all message lookups *must* be on either of the following formats:
       </p><p>
         </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>Typical static key lookup: <code class="computeroutput">[_ package_key.message_key]</code> - The message key and package key used here must be string literals, they can't result from variable evaluation.</p></li><li class="listitem"><p>
-            Static key lookup with non-default locale: <code class="computeroutput">[lang::message::lookup $locale package_key.message_key]</code> - The message key and package key used here must be string literals, they can't result from variable evaluation.</p></li><li class="listitem"><p>
+            Static key lookup with nondefault locale: <code class="computeroutput">[lang::message::lookup $locale package_key.message_key]</code> - The message key and package key used here must be string literals, they can't result from variable evaluation.</p></li><li class="listitem"><p>
             Dynamic key lookup: <code class="computeroutput">[lang::util::localize $var_with_embedded_message_keys]</code> - In this case the message keys in the variable <code class="computeroutput">var_with_embedded_message_keys</code> must appear as string literals <code class="computeroutput">\#package_key.message_key\#</code> somewhere in the code. Here is an example of a dynamic lookup:
             <code class="computeroutput">set message_key_array {
     dynamic_key_1  \#package_key.message_key1\#