Index: openacs-4/packages/acs-core-docs/www/i18n-requirements.html
===================================================================
RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/i18n-requirements.html,v
diff -u -r1.1 -r1.2
--- openacs-4/packages/acs-core-docs/www/i18n-requirements.html	28 Feb 2003 05:36:04 -0000	1.1
+++ openacs-4/packages/acs-core-docs/www/i18n-requirements.html	20 Aug 2003 16:20:16 -0000	1.2
@@ -1,21 +1,21 @@
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
-<html><head><meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"><title>OpenACS 4.6 Internationalization Requirements</title><meta name="generator" content="DocBook XSL Stylesheets V1.50.0"><link rel="home" href="index.html" title="OpenACS Documentation"><link rel="up" href="kernel-doc.html" title="Chapter 9. Kernel Documentation"><link rel="previous" href="permissions-design.html" title="OpenACS 4 Permissions Design"><link rel="next" href="groups-requirements.html" title="OpenACS 4 Groups Requirements"><link rel="stylesheet" href="openacs.css" type="text/css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><a href="http://openacs.org"><img src="images/alex.jpg" border="0"></a><table width="100%" summary="Navigation header" border="0"><tr><td width="20%" align="left"><a accesskey="p" href="permissions-design.html">Prev</a>&nbsp;</td><th width="60%" align="center">Chapter 9. Kernel Documentation</th><td width="20%" align="right">&nbsp;<a accesskey="n" href="groups-requirements.html">Next</a></td></tr></table><hr></div><div class="sect1"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="i18n-requirements"></a>OpenACS 4.6 Internationalization Requirements</h2></div></div><div class="authorblurb"><p>
+<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>OpenACS Internationalization Requirements</title><meta name="generator" content="DocBook XSL Stylesheets V1.58.1"><link rel="home" href="index.html" title="OpenACS Documentation"><link rel="up" href="kernel-doc.html" title="Chapter�13.�Kernel Documentation"><link rel="previous" href="db-api-detailed.html" title="Database Access API"><link rel="next" href="i18n.html" title="Internationalization"><link rel="stylesheet" href="openacs.css" type="text/css"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="navheader"><a href="http://openacs.org"><img src="images/alex.jpg" border="0"></a><table width="100%" summary="Navigation header" border="0"><tr><td width="20%" align="left"><a accesskey="p" href="db-api-detailed.html">Prev</a> </td><th width="60%" align="center">Chapter�13.�Kernel Documentation</th><td width="20%" align="right"> <a accesskey="n" href="i18n.html">Next</a></td></tr></table><hr></div><div class="sect1" lang="en"><div class="titlepage"><div><h2 class="title" style="clear: both"><a name="i18n-requirements"></a>OpenACS Internationalization Requirements</h2></div></div><div class="authorblurb"><p>
       by Henry Minsky, 
        <a href="mailto:yon@openforce.net" target="_top">Yon Feldman</a>, 
        <a href="mailto:lars@collaboraid.biz" target="_top">Lars Pind</a>,
        <a href="mailto:peter@collaboraid.biz" target="_top">Peter Marklund</a>, 
        <a href="mailto:christian@collaboraid.biz" target="_top">Christian Hvid</a>,
        and others.
   <br>
-          OpenACS docs are written by the named authors, but may be edited
+          OpenACS docs are written by the named authors, and may be edited
           by OpenACS documentation staff.
-        </p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-introduction"></a>Introduction</h3></div></div><p>
+        </p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-introduction"></a>Introduction</h3></div></div><p>
       This document describes the requirements for functionality in
       the OpenACS platform to support globalization of the core and optional
       modules. The goal is to make it possible to support delivery of
       applications which work properly in multiple locales with the
       lowest development and maintenance cost.
-    </p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-definitions"></a>Definitions</h3></div></div><div class="variablelist"><dl><dt><span class="term">internationalization (i18n)</span></dt><dd><p>
+    </p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-definitions"></a>Definitions</h3></div></div><div class="variablelist"><dl><dt><span class="term">internationalization (i18n)</span></dt><dd><p>
               The provision within a computer program of the
               capability of making itself adaptable to the requirements of different
               native languages, local customs and coded character sets.
@@ -30,23 +30,23 @@
             A product development approach which ensures that software products
             are usable in the worldwide markets through a combination of
             internationalization and localization.
-          </p></dd></dl></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="II._Vision_Statement"></a>Vision Statement</h3></div></div><p>The Mozilla project suggests keeping two catchy phrases in
+          </p></dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="II._Vision_Statement"></a>Vision Statement</h3></div></div><p>The Mozilla project suggests keeping two catchy phrases in
 mind when thinking about globalization:</p><div class="itemizedlist"><ul type="disc"><li><p>One code base for the world</p></li><li><p>English is just another language</p></li></ul></div><p>Building an application often involves making a number of
 assumptions on the part of the developers which depend on their own
 culture. These include constant strings in the user interface and
 system error messages, names of countries, cities, order of given
 and family names for people, syntax of numeric and date strings and
-collation order of strings.</p><p>The ACS should be able to operate in languages and regions
-beyond US English. The goal of ACS Globalization is to provide a
+collation order of strings.</p><p>The OpenACS should be able to operate in languages and regions
+beyond US English. The goal of OpenACS Globalization is to provide a
 clean and efficient way to factor out the locale dependent
 functionality from our applications, in order to be able to easily
 swap in alternate localizations.</p><p>This in turn will reduce redundant, costly, and error prone
 rework when targeting the toolkit or applications built with the
-toolkit to another locale.</p><p>The cost of porting the ACS to another locale without some
+toolkit to another locale.</p><p>The cost of porting the OpenACS to another locale without some
 kind of globalization support would be large and ongoing, since
 without a mechanism to incorporate the locale-specific changes
 cleanly back into the code base, it would require making a new fork
-of the source code for each locale.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="III._System/Application_Overview"></a>System/Application Overview</h3></div></div><p>A globalized application will perform some or all of the
+of the source code for each locale.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="III._System/Application_Overview"></a>System/Application Overview</h3></div></div><p>A globalized application will perform some or all of the
 following steps to handle a page request for a specific
 locale:</p><div class="orderedlist"><ol type="1"><li><p>Decide what the target locale is for an incoming page
 request</p></li><li><p>Decide which character set encoding the output should be
@@ -71,15 +71,15 @@
 Java which we will want to move to. So the design to meet the
 requirements will tend to rely on these capabilities, or close
 approximations to them where possible, in order to make it easier
-to maintain Tcl and Java ACS versions.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="IV._Use-cases_and_User-scenarios"></a>Use-cases and User-scenarios</h3></div></div><p>Here are the cases that we need to be able to handle
+to maintain Tcl and Java OpenACS versions.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="IV._Use-cases_and_User-scenarios"></a>Use-cases and User-scenarios</h3></div></div><p>Here are the cases that we need to be able to handle
 efficiently:</p><div class="orderedlist"><ol type="1"><li><p>A developer needs to author a web site/application in a
 language besides English, and possibly a character set besides
-ISO-8859-1. This includes the operation of the ACS itself, i.e.,
+ISO-8859-1. This includes the operation of the OpenACS itself, i.e.,
 navigation, admin pages for modules, error messages, as well as
 additional modules or content supplied by the web site
 developer.</p><p>What do they need to modify to make this work? Can their
 localization work be easily folded in to future releases of
-ACS?</p></li><li><p>A developer needs to author a web site which operates in
+OpenACS?</p></li><li><p>A developer needs to author a web site which operates in
 multiple languages simultaneously. For example, arsDigita.com with
 content and navigation in English, German, and Japanese.</p><p>The site would have an end-user visible UI to support these
 languages, and the content management system must allow articles to
@@ -92,12 +92,12 @@
 for other locales. This would include support for creating
 resources such as message catalogs, non-text assets such as
 graphics, and use of templates which help to separate application
-logic from presentation.</p></li></ol></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="Competitive_Analysis"></a>Competitive
+logic from presentation.</p></li></ol></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="Competitive_Analysis"></a>Competitive
 Analysis</h3></div></div><p>Other application servers: ATG Dyanmo, Broadvision, Vignette,
-... ? Anyone know how they deal with i18n ?</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="V._Related_Links"></a>Related
+... ? Anyone know how they deal with i18n ?</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="V._Related_Links"></a>Related
 Links</h3></div></div><div class="itemizedlist"><ul type="disc"><li><p><span class="emphasis"><em>System/Package &quot;coversheet&quot; - where all
-documentation for this software is linked off of</em></span></p></li><li><p><span class="emphasis"><em>Design document</em></span></p></li><li><p><span class="emphasis"><em>Developer's guide</em></span></p></li><li><p><span class="emphasis"><em>User's guide</em></span></p></li><li><p><span class="emphasis"><em>Other-cool-system-related-to-this-one
-document</em></span><a href="http://www.li18nux.net/" target="_top">LI18NUX
+documentation for this software is linked off of</em></span></p></li><li><p><span class="emphasis"><em><a href="i18n.html#i18n-design" title="Design Notes">Design document</a></em></span></p></li><li><p><span class="emphasis"><em><a href="i18n.html" title="Internationalization">Developer's guide</a></em></span></p></li><li><p><span class="emphasis"><em>User's guide</em></span></p></li><li><p><span class="emphasis"><em>Other-cool-system-related-to-this-one
+document</em></span></p><p><a href="http://www.li18nux.net/" target="_top">LI18NUX
 2000 Globalization Specification:
 http://www.li18nux.net/</a></p><p><a href="http://www.mozilla.org/docs/refList/i18n/l12yGuidelines.html" target="_top">Mozilla
 i18N Guidelines:
@@ -107,28 +107,32 @@
 Codes for the representation of names of countries and their
 subdivisions Part 1: Country codes
 http://www.niso.org/3166.html</a></p><p><a href="http://www.isi.edu/in-notes/iana/assignments/character-sets" target="_top">IANA
-Registry of Character Sets</a></p></li><li><p><span class="emphasis"><em>Test plan</em></span></p></li><li><p><span class="emphasis"><em>Competitive system(s)</em></span></p></li></ul></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI_Requirements"></a>Requirements</h3></div></div><p>Because the requirements for globalization affect many areas
+Registry of Character Sets</a></p></li><li><p><span class="emphasis"><em>Test plan</em></span></p></li><li><p><span class="emphasis"><em>Competitive system(s)</em></span></p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI_Requirements"></a>Requirements</h3></div></div><p>Because the requirements for globalization affect many areas
 of the system, we will break up the requirements into phases, with
 a base required set of features, and then stages of increasing
-functionality.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.A_Locales"></a>Locales</h3></div></div><p><span class="emphasis"><em>10.0</em></span></p><p>A standard representation of locale will be used throughout
+functionality.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.A_Locales"></a>Locales</h3></div></div><p><span class="emphasis"><em>10.0</em></span></p><p>A standard representation of locale will be used throughout
 the system. A locale refers to a language and territory, and is
 uniquely identified by a combination of ISO language and ISO
-country abbreviations.</p><blockquote class="blockquote"><p>See
+country abbreviations.</p><div class="blockquote"><blockquote class="blockquote"><p>See
 <a href="http://acs40.arsdigita.com/doc/acs-content-repository/requirements.html" target="_top">Content
 Repository Requirement 100.20</a></p><p><span class="emphasis"><em>10.10</em></span> Provide a consistent
 representation and API for creating and referencing a locale</p><p><span class="emphasis"><em>10.20</em></span> There will be a Tcl library of
 locale-aware formatting and parsing functions for numbers, dates
 and times. <span class="emphasis"><em>Note that Java has builtin support for these
 already</em></span>.</p><p><span class="emphasis"><em>10.30</em></span> For each locale there will be
-default date, number and currency formats.</p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.B_Associating_a_Locale_with_a_Request"></a>Associating a Locale with a Request</h3></div></div><p><span class="emphasis"><em>20.0</em></span></p><p>The request processor must have a mechanism for associating a
+default date, number and currency formats. <i>Currency i18n is
+NOT IMPLEMENTED for 5.0.0.</i></p><p><span class="emphasis"><em>10.40</em></span>Administrators can upgrade their
+servers to use new locales via the APM. <i>NOT IMPLEMENTED in
+5.0.0; current workaround is to get an xml file and load it
+manually.</i></p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.B_Associating_a_Locale_with_a_Request"></a>Associating a Locale with a Request</h3></div></div><p><span class="emphasis"><em>20.0</em></span></p><p>The request processor must have a mechanism for associating a
 locale with each request. This locale is then used to select the
 appropriate template for a request, and will also be passed as the
 locale argument to the message catalog or locale-specific
-formatting functions.</p><blockquote class="blockquote"><p><span class="emphasis"><em>20.10</em></span> The locale for a request should be
+formatting functions.</p><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>20.10</em></span> The locale for a request should be
 computed by the following method, in descending order of
 priority:</p><div class="itemizedlist"><ul type="disc"><li><p>get locale associated with subsite or package id</p></li><li><p>get locale from user preference</p></li><li><p>get locale from site wide default</p><p><span class="emphasis"><em>20.20</em></span> An API will be provided for
 getting the current request locale from the
-<tt>ad_conn</tt> structure.</p></li></ul></div></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.C_Resource_Bundles_/_Content_Repository"></a>Resource Bundles / Content Repository</h3></div></div><p><span class="emphasis"><em>30.0</em></span></p><p>A mechanism must be provided for a developer to group a set
+<tt>ad_conn</tt> structure.</p></li></ul></div></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.C_Resource_Bundles_/_Content_Repository"></a>Resource Bundles / Content Repository</h3></div></div><p><span class="emphasis"><em>30.0</em></span></p><p>A mechanism must be provided for a developer to group a set
 of arbitrary content resources together, keyed by a unique
 identifier and a locale.</p><p>For example, what approaches could be used to implement a
 localizable nav-bar mechanism for a site? A navigation bar might be
@@ -140,9 +144,9 @@
 functionality might include using templates, Java ResourceBundles,
 content-item containers in the Content Repository, or some
 convention assigning a common prefix to key strings in the message
-catalog.</p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.D_Message_Catalog_for_String_Translation"></a>Message Catalog for String Translation</h3></div></div><p><span class="emphasis"><em>40.0</em></span></p><p>A message catalog facility will provide a database of
+catalog.</p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.D_Message_Catalog_for_String_Translation"></a>Message Catalog for String Translation</h3></div></div><p><span class="emphasis"><em>40.0</em></span></p><p>A message catalog facility will provide a database of
 translations for constant strings for multilingual applications. It
-must support the following:</p><blockquote class="blockquote"><p><span class="emphasis"><em>40.10</em></span> Each message will referenced via
+must support the following:</p><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>40.10</em></span> Each message will referenced via
 unique a key.</p><p><span class="emphasis"><em>40.20</em></span> The key for a message will have
 some hierarchical structure to it, so that sets of messages can be
 grouped with respect to a module name or package path.</p><p><span class="emphasis"><em>40.30</em></span> The API for lookup of a message
@@ -165,11 +169,7 @@
 is modified, the other translations of that string can be flagged
 as needing update.</p><p><span class="emphasis"><em>40.90</em></span> The message lookup must be as
 efficient as possible so as not to slow down the delivery of
-pages.</p><p><span class="emphasis"><em>Design question: Is there any reason to implement
-the message catalog on top of the content repository as the
-underlying storage and retrieval service, with a layer of caching
-for performance? Would we get a nice user interface and version
-control almost for free?</em></span></p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.E_Character_Set_Encoding"></a>Character Set Encoding</h3></div></div><p><span class="emphasis"><em>Character Sets</em></span></p><p><span class="emphasis"><em>50.0</em></span> A locale will have a primary
+pages.</p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.E_Character_Set_Encoding"></a>Character Set Encoding</h3></div></div><p><span class="emphasis"><em>Character Sets</em></span></p><p><span class="emphasis"><em>50.0</em></span> A locale will have a primary
 associated character set which is used to encode text in the
 language. When given a locale, we can query the system for the
 associated character set to use.</p><p>The assumption is that we are going to use Unicode in our
@@ -180,19 +180,11 @@
 write other character sets. In particular, conversions to and from
 Unicode will need to be explicitly performed at the following
 times:</p><div class="itemizedlist"><ul type="disc"><li><p>Loading source files (.tcl or .adp) or content files from the
-filesystem</p></li><li><p>Accepting form input data from users</p></li><li><p>Delivering text output to a browser</p></li><li><p>Composing an email message</p></li><li><p>Writing data to the filesystem</p></li></ul></div><p><span class="emphasis"><em>Design question: Do we want to mandate that all
-template files be stored in UTF8? I don't think so, because
-most people don't have Unicode editors, or don't want to be
-bothered with an extra step to convert files to UTF8 and back when
-editing them in their favorite editor.</em></span></p><p><span class="emphasis"><em>Same question for script and template files, how do
-we know what language and character set they are authored in?
-Should we overload the filename suffix (e.g.,
-'.shiftjis.adp',
-'.ja_JP.euc.adp')?</em></span></p><p><span class="emphasis"><em>The simplest design is probably just to assign a
-default mapping from each locale to character a set: e.g. ja_JP
--&gt; ShiftJIS, fr_FR -&gt; ISO-8859-1. +++ (see new ACS/Java
-notes) +++</em></span>
-</p><div class="sect3"><div class="titlepage"><div><h4 class="title"><a name="Tcl_Source_File_Character_Set"></a>Tcl Source File Character Set</h4></div></div><blockquote class="blockquote"><p>There are two classes of Tcl files loaded by the system;
+filesystem</p></li><li><p>Accepting form input data from users</p></li><li><p>Delivering text output to a browser</p></li><li><p>Composing an email message</p></li><li><p>Writing data to the filesystem</p></li></ul></div><p>Acs-templating does the following.</p><div class="itemizedlist"><ul type="disc"><li><p>When the acs-templating package opens an an ADP or TCL file, it assumes the file is iso-8859-1.  If the output charset (OutputCharset) in the AOLserver config file is set, then acs-templating assumes it's that charset.  
+Writing Files</p></li><li><p>When the acs-templating package writes an an ADP or
+          TCL file, it assumes the file is iso-8859-1.  If the output
+          charset (OutputCharset) in the AOLserver config file is set,
+          then acs-templating assumes it's that charset.  </p></li></ul></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="Tcl_Source_File_Character_Set"></a>Tcl Source File Character Set</h4></div></div><div class="blockquote"><blockquote class="blockquote"><p>There are two classes of Tcl files loaded by the system;
       library files loaded at server startup, and page script files,
       which are run on each page request.</p><p><span class="emphasis"><em>Should we require all Tcl files be stored as UTF8?
       That seems too much of a burden on developers.</em></span></p><p><span class="emphasis"><em>50.10</em></span> Tcl library files can be authored
@@ -201,60 +193,63 @@
       filename.</p><p><span class="emphasis"><em>50.20</em></span> Tcl page script files can be
       authored in any character set. The system must have a way to
       determine the character set before loading the files, probably from
-      the filename.</p></blockquote></div><div class="sect3"><div class="titlepage"><div><h4 class="title"><a name="Submitted_Form_Data_Character_Set"></a>Submitted Form Data Character Set</h4></div></div><p><span class="emphasis"><em>50.30</em></span> Data which is submitted with a
+      the filename.</p></blockquote></div></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="Submitted_Form_Data_Character_Set"></a>Submitted Form Data Character Set</h4></div></div><p><span class="emphasis"><em>50.30</em></span> Data which is submitted with a
          HTTP request using a GET or POST method may be in any character
          set. The system must be able to determine the encoding of the form
-         data and convert it to Unicode on demand.</p><p><span class="emphasis"><em>50.35</em></span> The developer must be able to
+         data and convert it to Unicode on demand.  </p><p><span class="emphasis"><em>50.35</em></span> The developer must be able to
           override the default system choice of character set when parsing
-          and validating user form data.</p><p><span class="emphasis"><em>50.30.10</em></span> Extra hair: In Japan and some
+          and validating user form data. <i>INCOMPLETE - form
+          widgets in acs-templating/tcl/date-procs.tcl are not
+          internationalized.  Also, acs-templating's UI needs to be
+          internationalized by replacing all user-visible strings with
+          message keys.</i></p><p><span class="emphasis"><em>50.30.10</em></span>In Japan and some
            other Asian languages where there are multiple character set
            encodings in common use, the server may need to attempt to do an 
            auto-detection of the character set, because buggy browsers may
-           submit form data in an unexpected alternate encoding.</p></div><div class="sect3"><div class="titlepage"><div><h4 class="title"><a name="Output_Character_Set"></a>Output Character Set</h4></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>50.40</em></span> The output character set for a
+           submit form data in an unexpected alternate encoding.</p></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="Output_Character_Set"></a>Output Character Set</h4></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>50.40</em></span> The output character set for a
             page request will be determined by default by the locale associated
             with the request (see requirement 20.0).</p><p><span class="emphasis"><em>50.50</em></span> It must be possible for a
             developer to manually override the output character set encoding
             for a request using an API function.
-      </p></blockquote></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.F_ACS_Kernel_Issues"></a>ACS Kernel Issues</h3></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>60.10</em></span> All ACS error messages must use
+      </p></blockquote></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.F_ACS_Kernel_Issues"></a>ACS Kernel Issues</h3></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>60.10</em></span> All OpenACS error messages must use
 the message catalog and the request locale to generate error
-message for the appropriate locale.</p><p><span class="emphasis"><em>60.20</em></span> Web server error messages such as
+message for the appropriate locale.<i>NOT IMPLEMENTED for 5.0.0.</i></p><p><span class="emphasis"><em>60.20</em></span> Web server error messages such as
 404, 500, etc must also be delivered in the appropriate
 locale.</p><p><span class="emphasis"><em>60.30</em></span> Where files are written or read
 from disk, their filenames must use a character set and character
-values which are safe for the underlying operating system.</p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.G_Templates"></a>Templates</h3></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>70.0</em></span> For a given abstract URL, the
+values which are safe for the underlying operating system.</p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.G_Templates"></a>Templates</h3></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>70.0</em></span> For a given abstract URL, the
 designer may create multiple locale-specific template files may be
 created (one per locale or language)</p><p><span class="emphasis"><em>70.10</em></span> For a given page request, the
 system must be able to select an approprate locale-specific
 template file to use. The request locale is computed as per (see
-requirement 20.0).</p><p><span class="emphasis"><em>Design note: this would probably be implemented by
-suffixing the locale or a locale abbreviation to the template
-filename, such as foo.ja.adp or foo.en_GB.adp.</em></span></p><p><span class="emphasis"><em>70.20</em></span>A template file may be created for
+requirement 20.0).</p><p><span class="emphasis"><em>70.20</em></span>A template file may be created for
 a partial locale (language only, without a territory), and the
 request processor should be able to find the closest match for the
 current request locale.</p><p><span class="emphasis"><em>70.30</em></span> A template file may be created in
 any character set. The system must have a way to know which
 character set a template file contains, so it can properly process
-it.</p></blockquote><div class="sect3"><div class="titlepage"><div><h4 class="title"><a name="Formatting_Datasource_Output_in_Templates"></a>Formatting
+it.</p></blockquote></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="Formatting_Datasource_Output_in_Templates"></a>Formatting
 Datasource Output in Templates</h4></div></div><p><span class="emphasis"><em>70.50</em></span> The properties of a datasource
 column may include a datatype so that the templating system can
 format the output for the current locale. The datatype is defined
-by a standard ACS datatype plus a format token or format string,
+by a standard OpenACS datatype plus a format token or format string,
 for example: a date column might be specified as
 'current_date:date LONG,' or 'current_date:date
-&quot;YYYY-Mon-DD&quot;'</p></div><div class="sect3"><div class="titlepage"><div><h4 class="title"><a name="Forms"></a>Forms</h4></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>70.60</em></span> The forms API must support
+&quot;YYYY-Mon-DD&quot;'</p></div><div class="sect3" lang="en"><div class="titlepage"><div><h4 class="title"><a name="Forms"></a>Forms</h4></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>70.60</em></span> The forms API must support
 construction of locale-specific HTML form widgets, such as date
 entry widgets, and form validation of user input data for
-locale-specific data, such as dates or numbers.</p><p><span class="emphasis"><em>70.70</em></span> For forms which allow users to
+locale-specific data, such as dates or numbers.  <span class="emphasis"><em>NOT
+IMPLEMENTED in 5.0.0.</em></span></p><p><span class="emphasis"><em>70.70</em></span> For forms which allow users to
 upload files, a standard method for a user to indicate the charset
 of a text file being uploaded must be provided.</p><p><span class="emphasis"><em>Design note: this presumably applies to uploading
-data to the content repository as well</em></span></p></blockquote></div></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.H_Sorting_and_Searching"></a>Sorting and Searching</h3></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>80.10</em></span> Support API for correct collation
+data to the content repository as well</em></span></p></blockquote></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.H_Sorting_and_Searching"></a>Sorting and Searching</h3></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>80.10</em></span> Support API for correct collation
 (sorting order) on lists of strings in locale-dependent way.</p><p><span class="emphasis"><em>80.20</em></span> For the Tcl API, we will say that
 locale-dependent sorting will use Oracle SQL operations (i.e., we
 won't provide a Tcl API for this). We require a Tcl API
 function to return the correct incantation of NLS_SORT to use for a
 given locale with <tt>ORDER BY</tt> clauses in
 queries.</p><p><span class="emphasis"><em>80.40</em></span> The system must handle full-text
-search in any supported language.</p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.G_Time_Zones"></a>Time Zones</h3></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>90.10</em></span> Provide API support for specifying
+search in any supported language.</p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.G_Time_Zones"></a>Time Zones</h3></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>90.10</em></span> Provide API support for specifying
 a time zone</p><p><span class="emphasis"><em>90.20</em></span> Provide an API for computing time
 and date operations which are aware of timezones. So for example a
 calendar module can properly synchronize items inserted into a
@@ -265,20 +260,39 @@
 zone preference should be attached via a session or else UTC should
 be used to display every date and time.</p><p><span class="emphasis"><em>90.60</em></span> The default if we can't
 determine a time zone is to display all dates and times in some
-universal time zone such as GMT.</p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.H_Database"></a>Database</h3></div></div><blockquote class="blockquote"><p><span class="emphasis"><em>100.10</em></span> Since UTF8 strings can use up to
+universal time zone such as GMT.</p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.H_Database"></a>Database</h3></div></div><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>100.10</em></span> Since UTF8 strings can use up to
 three (UCS2) or six (UCS4) bytes per character, make sure that
 column size declarations in the schema are large enough to
 accomodate required data (such as email addresses in
-Japanese).</p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="VI.I_Email_and_Messaging"></a>Email and
+Japanese).  <i>Since 5.0.0, this is covered in the database
+install instructions for both PostGreSQL and Oracle.</i></p></blockquote></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="VI.I_Email_and_Messaging"></a>Email and
 Messaging</h3></div></div><p>When sending an email message, just as when delivering the
 content in web page over an HTTP connection, it is necessary to be
-able to specify what character set encoding to use.</p><blockquote class="blockquote"><p><span class="emphasis"><em>110.10</em></span> The email message sending API
+able to specify what character set encoding to use.
+</p><div class="blockquote"><blockquote class="blockquote"><p><span class="emphasis"><em>110.10</em></span> The email message sending API
 will allow for a character set encoding to be specified.</p><p><span class="emphasis"><em>110.20</em></span> The email accepting API will
 allow for character set to be parsed correctly (hopefully a well
-formatted message will have a MIME character set content type header) </p></blockquote></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-implementation-notes"></a>Implementation Notes</h3></div></div><p>
+formatted message will have a MIME character set content type header) </p></blockquote></div><p>Mail is not internationalized.  The following issues
+must be addressed.</p><div class="itemizedlist"><ul type="disc"><li><p>
+        Six different functions currently call ns_sendmail.  This
+        means that there are six different end points for sending
+        mail.  This should be brought down to no more than two (one
+        for acs_mail and one for acs_mail_lite), and ideally just
+        one.  Functions that currently call ns_sendmail directly
+        should instead call acs_mail_lite.
+</p></li><li><p>
+        Outgoing email functions (acs_mail and acs_mail_lite) must do
+        the following: 1) Determine the appropriate language or
+        languages to use for the message subject and message body.  2)
+        Encode the subject and body appropriately and set message
+        headers, in accordance with RFC 3282
+        (http://www.ietf.org/rfc/rfc3282.txt) and other RFCs.
+</p></li><li><p>Extreme Use case: Web site has a default language of Danish.  A forum is set up for Swedes, so the forum has a package_id and a language setting of Swedish.  A poster posts to the forum in Russian (is this possible?).  A user is subscribed to the forum and has a language preference of Chinese.  What should be in the message body and message subject?
+INCOMPLETE - The mail functions in acs_mail and acs_mail_lite
+are not internationalized.</p></li><li><p>Incoming mail should be localized.</p></li></ul></div></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-implementation-notes"></a>Implementation Notes</h3></div></div><p>
     Because globalization touches many different parts of the system,
     we want to reduce the implementation risk by breaking the
     implementation into phases. 
-  </p></div><div class="sect2"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-revision-history"></a>Revision History</h3></div></div><div class="informaltable"><table border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong"><em>Document Revision #</em></span></td><td><span class="strong"><em>Action Taken, Notes</em></span></td><td><span class="strong"><em>When?</em></span></td><td><span class="strong"><em>By Whom?</em></span></td></tr><tr><td>0.4</td><td>converting from HTML to DocBook and importing the document to the OpenACS
+  </p></div><div class="sect2" lang="en"><div class="titlepage"><div><h3 class="title"><a name="i18n-requirements-revision-history"></a>Revision History</h3></div></div><div class="informaltable"><table cellspacing="0" border="1"><colgroup><col><col><col><col></colgroup><tbody><tr><td><span class="strong">Document Revision #</span></td><td><span class="strong">Action Taken, Notes</span></td><td><span class="strong">When?</span></td><td><span class="strong">By Whom?</span></td></tr><tr><td>1</td><td>Updated with results of MIT-sponsored i18n work at Collaboraid.</td><td>14 Aug 2003</td><td>Joel Aufrecht</td></tr><tr><td>0.4</td><td>converting from HTML to DocBook and importing the document to the OpenACS
                kernel documents. This was done as a part of the internationalization of
-               OpenACS and .LRN for the Heidelberg University in Germany</td><td>12 September 2002</td><td>Peter Marklund</td></tr><tr><td>0.3</td><td>comments from Christian</td><td>1/14/2000</td><td>Henry Minsky</td></tr><tr><td>0.2</td><td>Minor typos fixed, clarifications to wording</td><td>11/14/2000</td><td>Henry Minsky</td></tr><tr><td>0.1</td><td>Creation</td><td>11/08/2000</td><td>Henry Minsky</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="permissions-design.html">Prev</a>&nbsp;</td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right">&nbsp;<a accesskey="n" href="groups-requirements.html">Next</a></td></tr><tr><td width="40%" align="left">OpenACS 4 Permissions Design&nbsp;</td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right">&nbsp;OpenACS 4 Groups Requirements</td></tr></table><hr><address>rmello at fslc.usu.edu</address><address><a href="mailto:vinod@kurup.com">vinod@kurup.com</a></address></div><a name="comments"></a><center><a href="http://openacs.org/doc/openacs-4/i18n-requirements.html#comments">View comments on this page at openacs.org</a></center></body></html>
+               OpenACS and .LRN for the Heidelberg University in Germany</td><td>12 September 2002</td><td>Peter Marklund</td></tr><tr><td>0.3</td><td>comments from Christian</td><td>1/14/2000</td><td>Henry Minsky</td></tr><tr><td>0.2</td><td>Minor typos fixed, clarifications to wording</td><td>11/14/2000</td><td>Henry Minsky</td></tr><tr><td>0.1</td><td>Creation</td><td>11/08/2000</td><td>Henry Minsky</td></tr></tbody></table></div></div></div><div class="navfooter"><hr><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="db-api-detailed.html">Prev</a> </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right"> <a accesskey="n" href="i18n.html">Next</a></td></tr><tr><td width="40%" align="left">Database Access API </td><td width="20%" align="center"><a accesskey="u" href="kernel-doc.html">Up</a></td><td width="40%" align="right"> Internationalization</td></tr></table><hr><address><a href="mailto:docs@openacs.org">docs@openacs.org</a></address></div><a name="comments"></a><center><a href="http://openacs.org/doc/i18n-requirements.html#comments">View comments on this page at openacs.org</a></center></body></html>