Conference vaxuum::document_ft

    
    That is a bug. I did overlook sending the <language>(name) information
    to the table of contents file; it will need to be done using a
    mechanism similar to the way we send it to the indexer.
    
    Meanwhile, you should be able to put the language strings in a separate
    DESIGN file. 
    
    -patti

 Making an entry in a design file is not really a good solution: it
 means that I need to have a double number of almost identical 
 files for each available document type. I'm not looking forward to
 do that. 

 b.t.w.: the local language strings will be part of the V1 kit or
 will we always have to make our own text strings? 

Theo

    
    I will see if I can put a fix in the local elements file for
    the contents problem.
    
    I would have like to distribute the string translation file(s) but
    haven't as yet received the necessary information from IPG. We
    should also be able to handle this using a special local elements
    file. 
    
    patti

I don't think it happens only with <LANGUAGE>.I made the following local
replacements and they work very nicely except the \gdef\Contentsname{Inhalt}.
Correct or have I done something wrong ( I'm working with the product for
2 days now ) ????

      \gdef\Ordernumbername{Bestellnummer}
      \gdef\Contentsname{Inhalt}
      \gdef\Chaptername{Kapitel}
      \gdef\Copyrightword{Copyright \copyright}
      \gdef\Copyrightreserved{Alle Rechte bei DEC Austria,Product Mgtm. and Promotion .}
       \gdef\Copyrightprintlocation{Gedruckt in Wien,�sterreich}
      \gdef\Prefacename{Vorwort}
     %
     %%%%%%%%%%%%%%%%%%%%
     % \DOCUMENTacknowledgement
     %
     \gdef\DOCUMENTacknowledgement{% 
     \block{1}Dieses Dokument wurde mit VAX DOCUMENT, Version 1.0 generiert
     \par}

    
    What DESIGN are you using? We caught and fixed for V1.0 a few
    DESIGN files that had English definitions for contents names.
    
    

  We would also appreciate it, if the <LANGUAGE> dependent definitions
  would extend to the title pages. E.g. the text 
  "Revision date/Update Information:"  is coded as text in the designs.
  If this is made to a \revisionline command, we could \gdef it to the
  local equivalent. It looks a bit daft to have everything in dutch and
  suddenly get this little bit of english in between...

  (and modifying 2*n design files is *not* the solution to the problem -
  that's a painful disaster)

Theo

    
    Theo,
    
    You got me on the <revision_info> text. That did not find its way
    to the /LANGtextstrings for V1.0. Note that this an instance where
    the default text can be overridden in the tag, for instance:
    
    <revision_info>(revisiontitle\revisiontext)
    
    

I was using the MANUAL design.

Is there a workaround ( even replacing something in an intermediate file
would do ).

	Regards,

		Gerold

Re .5 and .6:

 Same request for the text that is now part of the \def\ordernumber
 Then we can change it to "Bestelnummer" ...

Theo

   Building a single chapter of a book using the 
    
       DOCUMENT chapter doctype dest /PROFILE=profile

   command also defaults back to the English "Chapter" titles...
   
   It looks like the <LANGUAGE> tag implications have to be looked at 
   again...


Theo

    
    The doctypes in which 'Order Number' or 'Order No.' are written
    explicitly and not using \Ordernumbername (which can be overridden
    in local elements, for now), are MANUAL, MANUAL.GUIDE, HARDWARE,
    SOFTWARE.BROCHURE, and REPORT.TWOCOL. You can work around this
    problem by copying the related DESIGN file from DOC$STANDARD_FORMATS,
    changing the text 'Order Number' to '\Ordernumbername' and
    defining the modified DESIGN file as a local doctype. I will need
    to decide whether to make a new V1.0 kit with these corrections.
    
    The problem with the <language> tag not having an effect in a book
    build is also a bug. It can be partially worked around by placing
    the <LANGUAGE> tag in the source file for the first element in the
    book. This will place the correct string in the output. It will
    not, however, do the correct thing in the case of an element build,
    nor will it write the correct string to the table of contents or
    index. I will provide a fix for this bug as soon as I can when
    I get back from vacation.
    
    I appreciate very much the patience of our users in Europe who
    have had to put up with these sneaky little 'gotchas'. We also
    appreciate the very thorough audit from IPG on internationalization.
    
    patti

  Another "gotcha" now we're talking about languages. I discovered in
  some design files hard coded  \case \month January \or February ...

  May I ask to consider to replace these by either \January etc
  or \Monthi etc. so we can modify these too to our own tongue?

  On the same trail, if  there is a Wednesday somewhere, replace it
  by \Wednesday or \dayiii ?

  Cannot think of any other "local" thing we might want as our own 
  language version, but if we stumble on one, we'll let you know.

\def\TDK{\if \dutch \then Theo de Klerk
         \else \if \japanese \then magnetic tape
         \else Anonymous \fi\fi
         }

  While entering the previous reply, of course  the next one creeps up:

  in LETTER styles, the  TO / FROM / SUBJECT  etc. are also keywords
  that need to be modifiable.

Theo

 I'm not quite sure how citizens of the USA look upon Western Europe, but
 certainly the dotted lines are traced the wrong way and - in other
 conferences - might lead to another war. It's alright for you (non-)trekkies
 to speak something of the same language from  Alaska (we know all about
 that place now with that many free sample documents!) down to Texas,
 but the file CUP$EUROPE_ELEMENTS.TEX needs some improvement.

 - The German <language> tag results in "Printed in Vienna" (well, Wien
   actually). Since WW II I don't think Austria and Germany were so 
   closely related that their centre is now Vienna.  Some would prefer
   Berlin, reality dictates Bonn...

 - The Italians get German names for months... that also sounds like a
   relic of WW II...

I appreciate the better working of contents/index file entries in local
language now, have updated the dutch version with everything needed, in
cooperation with our Translation Engineering. Now for proper hyphenation.
I just cannot wait. 

P.S.

I've written a small "Cookbook" for the layman to start using Document
(even our local secretaries get interested). Having done something similar
in the past for LaTeX,  the booklet uses the left pages to show the
actually typed text, and the right pages to show the Document processed
results. The text itself talks loosely on how to work with Document and
explains/demonstrates the obvious features as chapters/headers/lists/tables/
figures/bookbuilding/overheads. This "monkey see, monkey do" approach
shows to be very effective and reduces the threshold for people to look
into the proper documentation. So we're all ready to go. Document, here
we come!

Theo

    Theo, your "cookbook" sounds great.  Can you get us a copy?
    Will we be able to print it over here? :-)
    
    (as for our understanding of other lands, other languages and
     other political systems -- the British gave up on trying to
     educate us colonists back in the 1770's -- it's good that you
     are still trying...)
    
    bill

>    Theo, your "cookbook" sounds great.  Can you get us a copy?
>    Will we be able to print it over here? :-)
    
 The Cookbook actually is a Kookboek - that is it is dutch written to
 lower/remove the barrier for using Document as first time user.
 The text losely describes the usual Document features as chapters and
 lists, but on the left hand side we inserted the literal SDML source
 next to the Document output on the righthandside. 

 The Kookboek is a set of files which are available if you want them -
 perhaps we should translate them into english too. On the other hand
 perhaps some parts of the "Step-by-step" guide could be restructured
 this way.  

 The approach definitely works here: you can talk till your tongue drops
 out, but give 'm an example to work from and they go ahead all by themselves.
 The fact that some secretaries want to use it (they're fed up with their
 LQPs) to me sounds wonderful.

Theo

    
    re .13 TO, FROM, etc.
    
    Theo is correct; these are language-modifiable in the standard
    LETTER doctype. Unfortunately, the DEC internal MEMO doctype did
    not get the parameterization. Will fix for Europe kit update/patch
    when that is ready.