From owner-cvs-all@FreeBSD.ORG Fri Mar 17 16:07:41 2006 Return-Path: X-Original-To: cvs-all@FreeBSD.org Delivered-To: cvs-all@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E505216A446; Fri, 17 Mar 2006 16:07:40 +0000 (UTC) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (kazi.fit.vutbr.cz [147.229.8.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 209EC43D58; Fri, 17 Mar 2006 16:07:32 +0000 (GMT) (envelope-from cejkar@fit.vutbr.cz) Received: from kazi.fit.vutbr.cz (localhost [127.0.0.1]) by kazi.fit.vutbr.cz (envelope-from cejkar@fit.vutbr.cz) (8.13.5/8.13.5) with ESMTP id k2HG7UVb002559 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Mar 2006 17:07:30 +0100 (CET) Received: (from cejkar@localhost) by kazi.fit.vutbr.cz (8.13.5/8.13.1/Submit) id k2HG7Tlx002558; Fri, 17 Mar 2006 17:07:29 +0100 (CET) (envelope-from cejkar@fit.vutbr.cz) X-Authentication-Warning: kazi.fit.vutbr.cz: cejkar set sender to cejkar@fit.vutbr.cz using -f Date: Fri, 17 Mar 2006 17:07:29 +0100 From: Rudolf Cejka To: Ceri Davies , Remko Lodder , doc-committers@FreeBSD.org, cvs-doc@FreeBSD.org, cvs-all@FreeBSD.org Message-ID: <20060317160729.GA98352@fit.vutbr.cz> References: <20060311152536.GD73523@submonkey.net> <20060313152017.GA24077@fit.vutbr.cz> <20060314100021.GA36929@submonkey.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060314100021.GA36929@submonkey.net> User-Agent: Mutt/1.4.2.1i X-Scanned-By: MIMEDefang 2.54 on 147.229.8.12 Cc: Subject: Re: cvs commit: www/en where.sgml X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Mar 2006 16:07:41 -0000 Ceri Davies wrote (2006/03/14): > > 3) Recently I have found yet another problem: Your commit > > www/share/sgml/includes.navdownload.sgml 1.3, which added > > %relincludes; > > into includes.navdownload.sgml file, has bad impact, that it is not > > possible to change definitions from includes.release.sgml in translations > > in a standard way anymore, which is to change www//includes.sgml. > > Do you have any idea, how to solve this? I did not find anything good yet. > Does it work if that declaration moves to the English includes.sgml (if > there is one)? If you mean %relincludes;, I think that not. You need it very early for %beta.testing and %beta2.testing for marked sections in includes.navdownload.sgml. Maybe it would help to move %beta.testing and %beta2.testing out from includes.release.sgml and make special file for them, however locality will be bad then and I'm afraid I would not like this solution. File includes.navdownload.sgml has to be included very early too, because it has to define entity &nav; before includes.header.sgml tries to define it as empty entity. > Failing that, is is possible to declare an ENTITY within > a marked section? > If so, we could use a similar approach in the > includes as /usr/include does perhaps? I could not imagine anything to do in this way. I'm looking at it once again, but I'm not sgml master. Maybe I can see two solutions: 1) Instead of using %navincludes; %includes; it should be sufficient to use just %includes; without calling %navincludes;, which could be moved to share/sgml/includes.sgml between %includes.release; and %includes.header;, however this solution would be just for case for includes.release.sgml. Is it possible to say in includes.header.sgml that if there is defined %navincludes;, call it, otherwise define ? 2) It seems to me that it is possible to remove from share/sgml/includes.header.sgml at all and depend on that every occurence of %includes; defines %navincludes; too. It has to be in that order: %navincludes; must be called after %includes;, so every file should be changed then, to have here clear including rules (and %relincludes; can be then removed from share/sgml/includes.navdownload.sgml). It seems that there is no file, which depends on default , so no other steps would be needed. If there would be any need for empty nav in the future, we can create empty includes.navempty.sgml, which can substitute current in includes.header.sgml. However everything is untested for now, if there are any output differences after that modifications. -- Rudolf Cejka http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic