X-VM-v5-Data: ([nil nil nil nil nil nil nil nil nil] ["3526" "Thu" "13" "February" "1997" "21:41:18" "+0100" "Frank Mittelbach" "Frank.Mittelbach@uni-mainz.de" nil "78" "Re: International documents" "^Date:" nil nil "2" nil nil nil nil] nil) Received: from listserv.gmd.de (listserv.gmd.de [192.88.97.1]) by mail.Uni-Mainz.DE (8.8.5/8.8.4) with ESMTP id WAA32585 for ; Thu, 13 Feb 1997 22:32:19 +0100 (MET) Received: from listserv.gmd.de by listserv.gmd.de (LSMTP for OpenVMS v1.1a) with SMTP id <10.30F4C3F9@listserv.gmd.de>; Thu, 13 Feb 1997 22:32:00 +0100 Received: from RELAY.URZ.UNI-HEIDELBERG.DE by RELAY.URZ.UNI-HEIDELBERG.DE (LISTSERV-TCP/IP release 1.8b) with spool id 100769 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 13 Feb 1997 22:31:53 +0100 Received: from kralle.zdv.Uni-Mainz.DE (kralle.zdv.Uni-Mainz.DE [134.93.8.158]) by relay.urz.uni-heidelberg.de (8.7.6/8.7.4) with ESMTP id WAA28179 for ; Thu, 13 Feb 1997 22:31:52 +0100 (MET) Received: from frank.zdv.uni-mainz.de (Ufrank@localhost) by kralle.zdv.Uni-Mainz.DE (8.8.5/8.8.5) with UUCP id WAA29682 for LATEX-L@RELAY.URZ.UNI-HEIDELBERG.DE; Thu, 13 Feb 1997 22:28:26 +0100 (MET) X-Authentication-Warning: kralle.zdv.Uni-Mainz.DE: Ufrank set sender to frank.zdv.uni-mainz.de!latex3 using -f Received: (from latex3@localhost) by frank.zdv.uni-mainz.de (8.6.9/8.6.9) id VAA24041; Thu, 13 Feb 1997 21:41:18 +0100 References: Message-ID: <199702132041.VAA24041@frank.zdv.uni-mainz.de> Reply-To: Mailing list for the LaTeX3 project In-Reply-To: Date: Thu, 13 Feb 1997 21:41:18 +0100 From: Frank Mittelbach Sender: Mailing list for the LaTeX3 project To: Multiple recipients of list LATEX-L Subject: Re: International documents Status: R X-Status: X-Keywords: X-UID: 1803 Hans Aberg writes: > Therefore, I think that a discussion that centers around a few standard > formats only is not very helpful. Several of the standard formats, like the well but that is exactly what i'm trying to say. I don't intend to produce hard coded standards but to develop an interface for specifying language-dependent information. TO DO SO i first want to have a close look at the problem area rather then starting from the interface side. up to now things have been developed by looking only at individual problems developing individual solutions and putting software layer over software layer. > Duden German grammatical rules I think, were created by collecting some > general practise rules, and simply, rather brutally, make a selection from > that. This way, one can create beautiful standards, but the problem is that > today, our world is too complex for this to work. yes and no. i really don't think that i want to go into the philosphical discussion on whether standards are useful, helpful, rubbish, ... the world is complex but most users still like it simple and if it isn't simple then many of them use what they get automatically (for that reason you have a de facto standard of latex's report class which you can find in many books because people didn't bother to change anything other than the the bare minimum they had to) --- let's hope that this is just because it is so difficult to do otherwise and not because nobody cared. same goes for documents produced in, say, MS-word: how many users do you think do bother doing something about the hyphenation this program produces (other then turning it off comepletely)? not many. so again: what i'm asking for is about items the user might want to or have to change because the document is written in a certain language. what are these items? which one haven't been covered so far in the dicussion? or to approach the topic differently: - what needs to be "settable" no matter how for the moment if a document is written completely in language foo (note that i don't say anything about settable to a single value) - what would you like to be able to set (again not how at the moment) if the document is set in language foo but some parts, say chapters are in languages bar and some in baz - what needs to be adjusted when individual phrases or other small items are set in a language different from the surrounding language? do we get any further looking at the topic this way? and again: any interface that might be developed will ultimatively result in the ability to produce "defaults" that can be used; but this is not the purpose of the exercise. the purpose is to lay a foundation to describe what needs to be covered by such an interface and once there is an interface its purpose is to allow the user to easily adjust (perhaps starting from a default) the settings to his or her desire. perhaps it is the case that babel covers all the issues (that can be set in TeX) and the only problem with it is that its interface is not sufficient flexible to allow for small or large modifications, but then perhaps it isn't covering important cases. certainly its interface is not of a kind that makes it easy to do any modifications other than choosing one or the other "default" and usually that means (for most users) there isn't much adjustable at all. but before going into interface questions, what are the items related to language? what are the answers to the above questions? good night frank