(The User Area): The description of the common block grammar contained

	many errors.  State that everything is encoded as HOLLERITHs,
	and that they in turn contain datatypes.  Removed "list" and
	"elems"; added "string-list".  Added the "language" setting.
	(Bug 124).

doc/Protocol-A.texi

@@ -9002,25 +9002,16 @@ what you name your client's block.
 
 @section The Common Block
 
-This defines the theoretical structure of the common block.  The real
-world probably does not agree entirely with this, and it is likely to
-change just as soon as I have time to define something better.  In the
-mean while you're probably better off ignoring the common block and
-storing all your settings in a client block.  The Emacs lisp client uses
-the common block, but I have a feeling that it might store data that
-other clients can't read.
-
-The common block contains a list of variable settings.  Each variable
-setting consists of a name, some whitespace, and a value.  Settings are
-separated by a line feed character.  As of protocol version 10, values
-can be integers, strings, booleans or lists.  The encoding is such that a
-value is encoded as a single protocol A token.  That means that strings
-and lists are both encoded as HOLLERITHs.  The reason for this is to
-simplify for clients that need to ignore the value, and so it is
-possible to add new value types without confusing old clients (new types
-will be encoded as HOLLERITHs.)
-
-The grammar below sort of defines the syntax of the common block.
+This defines the structure of the common block.  The common block
+contains a list of variable settings.  Each variable setting consists
+of a name, some whitespace, and a value.  Settings are separated by a
+line feed character.  The values can be of several different types
+(such as integers, strings, booleans, lists of stuff) but they are all
+encoded as HOLLERITHs.  The reason for this is to simplify for clients
+that need to ignore the value, and so it is possible to add new value
+types without confusing old clients.
+
+The grammar below defines the syntax of the common block.
 
 @c ispell-ignore
 @example
@@ -9029,57 +9020,76 @@ settings        :   settings setting
                 |   /* empty */
 setting         :   variable ' ' value '\n'
 variable        :   [A-Za-z-_0-9]+
-value           :   boolean
-                |   HOLLERITH
-                |   list
-                |   integer
+value           :   HOLLERITH
+@end example
+@c ispell-end-ignore
+
+The values contain structure within the HOLLERITH.  The following
+grammar defines the datatypes that are currently used.  Clients must
+be prepared to ignore values that have other datatypes.
+
+@c ispell-ignore
+@example
 boolean         :   1 | 0
 integer         :   -?[0-9]+
-list            :   integer elems       // Encoded in a HOLLERITH
-elems           :   elems value
-                |   empty
+string-list     :   string-list ' ' HOLLERITH
+                |   HOLLERITH
 @end example
 @c ispell-end-ignore
 
 Currently the following variables are used, but more may be added, and
-as of protocol version 10, clients should be able to cope with variables
-they know nothing of in the common block, as long as they are of one of
-the types above.  Pre-protocol version 10 clients can't deal with
-HOLLERITHs in the common block.
-
-As of protocol 10 the following variables are stored in the common
-block:
+clients must cope with variables they know nothing of in the common
+block.  (Doing so is easy, as all values are encoded as HOLLERITHs.)
 
 @table @code
 @item created-texts-are-read
 True if the user wants texts s/he creates to be marked as read
-automatically.  Boolean.
+automatically.  @code{boolean}.
 
 @item dashed-lines
 True if the user wants dashed lines around the text body when it's
-displayed.  Boolean.
+displayed.  @code{boolean}.
 
 @item presence-messages
 True if the user wants messages about people logging in and logging out
-of LysKOM.  Boolean.
+of LysKOM.  @code{boolean}.
 
 @item print-number-of-unread-on-entrance
 True if the user wants to see the number of unread texts when entering a
-conference.  Boolean.
+conference.  @code{boolean}.
 
 @item read-depth-first
-True if the user wants to read text in depth-first order.  Boolean.
+True if the user wants to read text in depth-first order.  @code{boolean}.
 
 @item reading-puts-comments-in-pointers-last
 True if the user wants the client to display comment links after the
-text body.  Boolean.
+text body.  @code{boolean}.
 
 @item confirm-multiple-recipients
 True if the user wants the client to ask for confirmation before sending
-a text to many conferences.
+a text to many conferences.  @code{boolean}.
 
 @item default-mark
-The default mark to set on marked texts.
+The default mark to set on marked texts.  @code{integer}.
+
+@item language
+Preferred languages, in priority order.  @code{string-list}.
+
+This contains a list of ISO 639 language codes.  ISO 639-2 should be
+used for languages that have a 2-character language code.  For other
+languages, ISO 639-1 should be used.
+@uref{http://lcweb.loc.gov/standards/iso639-2/langcodes.html} contains
+a list of the current language codes.
+
+The client should configure its user interface to use the first
+language in the list that it supports.  Example: a client that
+supports English and Swedish would use:
+@itemize @bullet
+@item Swedish if the list is @samp{2Hfr 2Hsv 2Hen}
+@item English if the list is @samp{2Hen 2Hsv 2Hfr}
+@item either if the list is @samp{2Hes 2Hfr}
+@end itemize
+
 @end table