Lout for non-English users

[Jeff Kingston]

As part of my preparation of the forthcoming release of
Basser Lout, I am now giving serious thought to the
issues of porting to languages other than English.
Below I give my current plan for resolving these
issues.  Please let me have any comments at all about
this plan now, while there is still time to correct it.

(1) I do not intend to support versions of the standard
packages in which the commands, like @Text and @Chapter,
are translated into other languages.

(2) The forthcoming release will support ISO-LATIN-1 as
usual, but not yet east Asian languages such as Japanese.
Level 2 PostScript does support them, so no doubt these
will be added in time.

(3) Some users have asked for two-character ASCII
encodings of the accented characters, such as "u and
so on.  My current thinking is not to supply these, on
the grounds that the right solution is to get an
ISO-LATIN-1 keyboard and Lout should not try to prop
up the old ways.

(4) Even if a document contains accented characters,
Lout does now produce 7-bit ASCII PostScript output,
depending on a flag set at installation time, and this
will continue.

(5) Here is my general strategy for handling languages
other than English.  I plan to add a -l flag to the Lout
command line, so that one could type for example

        lout -l Danish ...

or whatever particular ASCII (not ISO-LATIN-1) string
the Danes decide they want, to get Danish.  No further
effort would be required.  The default value would be
English, and regular users of Danish would be expected
to create a shell script or alias so that they don't have
to type -l Danish all the time.  It would not be possible
under my plan to type

        @Document
            @Language { Danish }

and get Danish.  This latter approach seems to have
implementation problems, since by the time we reach the
word Danish we have already read vast numbers of files,
with no way of knowing that we wanted the Danish versions.
The command line flag by contrast is available from the
beginning, and it can be (and would be) used to alter the
search path for system hyphenation, include, data, and even
font files, so that a Danish system directory is searched
first, and if the file is not found there, only then is
the default English directory searched.  This will allow
those files that need to be changed (call them "varying")
to have Danish versions, and the ones that don't (call
them "common") to be kept in only one place.

(6) The following seems to be a complete list of all the
places where literal words that become part of the output
file appear in the current Lout distribution:

  (a) Certain words in the DocumentLayout package,
      such as Chapter and Section, all collected
      in definitions near the top of the file (dl);

  (b) The hyphenation classes and patterns (lout.hyph)

  (c) The hyphenation exceptions in the DocumentLayout
      package (dl);

  (d) Certain words in the database of reference styles,
      such as Tech. Rep. (refstyles.ld);

  (e) Roman numerals, used for labels (standard.ld);

  (f) The 26 letters of the alphabet, used for labels
      (standard.ld);

  (g) The names of the months, used by @Date, and the
      names of the days of the week, not currently used
      (standard.ld).

My plan is to break standard.ld into two databases, one of
things that are common to all languages, and the other of
things that vary between languages.  Let's call these
common.ld and varying.ld for the time being.  There would
be one copy only of common.ld, in the default English system
directory, and multiple copies of varying.ld, one in each
language's system directory.  Cases (a)-(g) above would be
handled as follows:

  (a) Words like Chapter and Section would be moved into
      the varying.ld database, making dl language
      independent so that it becomes common.

  (b) There would be a hyphenation patterns file in each
      language's system include directory, if such a file
      was available;

  (c) The hyphenation file format would be extended to
      include an exception list.  This would mean that all
      information about hyphenation would be in the one file,
      there would be no need for separate definitions for
      capitalized and uncapitalized exceptions, and no need
      for exception definitions in the dl file;

  (d) refstyles.ld would be varying, or possibly it might be
      common with references to varying.ld for varying words;

  (e) Roman numerals seem to be common to all languages
      (is this right?) so they would go into common.ld, in
      fact it seems that common.ld would hold nothing else;

  (f) The 26 letters of the alphabet seem to be varying:  in
      a modified standard.ld sent to me recently from Denmark,
      the author added a 27th, 28th, and 29th entry to the
      standard 26; and as we go further afield, to Russian
      say, they are certainly varying;

  (g) The month names and weekday names go into varying.ld.

Jeff Kingston