RFC: even better docbuild speedup solution ;)

Hi! Following up on my suggestion to speed up phpweb+html build by building only one of them, and generating the headers and footers as required, I beleive I have a solution to cut off most of the build time if some older version is available in the same language or an English build is available and a translated version is needed. Here it is ;) The scenario is explained for translation build speedup, though the same technqiue can be used for updating the same language build. There are many advantages, so if you keep reading on, I hope you'll find interesting stuff here ;) 1. Do not output any TOC info into the chunks (HTML/PHP files). - Placeholder in place of header and footer - Placeholder in place of all TOC parts (on frontpages, function listings on ref.* pages, etc) ~ Easy to do, only need to make the sheets more dumb ;) 2. Create separate TOC file output in a PHP or XML structure ~ This is easy starting from the HTMLHelp .hhp sheet, which does the same but output's .hhp format 3a. English output files can be generated out of (1) and (2), replacing the TOC placeholders with info gathered from (2) with a PHP script operating with str_replace and/or regexps. ~ Most of the time easy stuff, depends on the complexity of the structure created in (2). ================================== 3b. To generate a 'translated' documentation, keep the English intermediate files, and configure phpdoc with the translation. Run a script which selects the IDs which are translated. This can effectively collect the IDs of function documentation translated, etc. ~ Easy, only need to grep IDs out of XML files. 4. Generate a new TOC file (this will contain the English titles and names for English content, and translated names for translated content). 5. Run the full generation process patched with some code to ignore the chunk generation for IDs not in the list created above. This will eventually let the files be in context (as part of the full manual), but won't generate anything which is not translated. 6. To create translated output files now, overwrite the English intermediate chunks created in (1), with the translated ones created in (5), and generate the TOC parts from the TOC created in (4). Anyone who cared to read so far can see now, that this is not an overcomplicated process. The key is that we cannot run the generation of chunks individually, as they would not find the link endpoints, and other stuff. So we need to run the generation from the top. But we can intervene when a chunk is started to be created and can say, that it does not need to be created, as it would be fully English. So if we have a list of chunks to be built, we can check if the chunk to be created is on the list or not. If not, then we can skip the chunk creation. Advantages: - no different phpweb and html builds anymore, as they are the same if we replace the TOC and header/footer parts with placeholders => nearly half the build time for the sum of these two - every toc part will be in the correct language [mixed with English only as needed] and every other navigation link will contain the text relevant for that translation - files with English content won't contain translated gentext parts anymore [quite a funny 'buggy' thing now :)] - docbuild speed will further be significantly improved the more languages you would like to build at a time - the very same method can be used for updated documentation generation too (just in this case, the ID list should not be the updated IDs list, and not the translated IDs list) - probably possible to build non-isolatin1 compatible files with xsltproc (which is not possible now, I'll explain this in another letter, if somebody is interested) Disadvantages: - double disk space needed (intermediate English files + intermediate translated files + final output files) [this is probably not a big problem, as we have far more diskspace then time] - no immediate result (two phase building) [the placeholder replacements will probably be quick, if the big TOC file format is properly defined] As I don't have the time to do this right away, I am waiting for comments on it, and it will probably go to the RFC dir archived, and as someone has time to play with it, Goba