> OK. Please do not only ACK my folder ideas, but please also > give your opinion. For example whether it would be better > to put condigure things into install/configure or configure/.
Installation -> install/ Configure Options -> install/configure php.ini Stuff/configuration directives -> install/settings my 2 cents > it seems to me that it is right. In this vision, the configure > options existed inside the logical parts (eg. databases, text > processing, etc), side by side with functions, ini settings, > feature descriptions, conceptual indexes, and so on... > So what I would like to say with this is configure/ or > configure/install is only a temporary place for this thing > in my eyes. Though as my vision may be completely bad, this > may also be a final place, so it needs to be carefully > choosen... I talked to Hartmut about this. IMHO you are right when talking about temporary places. When it is finished, stuff like --with-gd should be in the file which describes graphics. > this breakup structure. You have a TOC and some text in > install.xml, and text in other install.notconfigurebutsomeother.xml > files. Lets say we introduce a new server, BadBlue as > install.badblue.xml, and we add it into the English > install.xml TOC. This server will not appear in translations > as long as they update their install.xml. You are right. Im not so very familiar with Docbook structures, so putting the entities in manual.xml or any other "general" place might be the best to do. > IMHO to support the automatic english file usage, we > need to have a file with no translateable content, > and all the content need to reside in "content files". Yes, this seems to be the best way to slve this "problem". > This is easy to accomplish with install, not that > easy with install.configure, I'll look over this > thing... I will, too . > What others think about this? This will be a convention, > so a community agreement need to be made :) Absolutely. I am not the "king of manual", so I can only say, what I think. Mark
