--- Gabor Hojtsy <[EMAIL PROTECTED]> wrote: > > May I suggest you just duplicate the entire > current manual structures for > > the new manual(s) and don't add any translation > directories. That way > when > > someone decides they have to have the new manual > in their native language > > you don't have to work so hard to support it. > They will eventually... > > Uh, it's not that easy. We have separate mailing > lists for translations > and separate CVS modules for every translation. > Well, if we duplicate all > these, we get a huge mess... If we push all users > manual content one subdir > down and make a new subdir for developers manual > content (in all phpdoc > modules), then we get a huge mess (there will be no > CVS history for files, > updates will get even harder).
Yep, It might be simpler to move the chapters/appendices that will make the "Devloper's manual" (or whatever name we decide) to its own top level CVS dir tree, and then handle that part alone. As that is the (relatively) newer part of the current manual, it will generate the less amount of damage/problems. Now, separating the rest into a Language and a Function references will be hairier and short of splitting them and then hand-fixing the CVS files, I have no simple ideas/solutions to propose. > Actually I don't > think so that someone can > write a PHP extension if he even don't know > English... Agree there. If we separate the "Howto", Zend engine, streams, etc. into its own 'phpdoc-dev' (or something like that), then it will be clear that is not something to be translated. > PEAR, PHP-GTK, TSRM and other projects also copied > the build system, so we > have quite differently evolved build systems > everywhere. Copying the build > system does not help IMHO, but increases confusion, > as different projects > modify that initially same build system to their > needs in different ways, > so you cannot just jump in and work with another > build system. Indeed, in particular in PEAR we are working towards allowing simpler generation of class documentations. As we are already using javadoc-style comments in the code, we could generate the DocBook prototypes programatically, the PEAR::PHPDoc tool is being modified for that purpose. Also there are some OpenOffice -> DocBook filters being developed to simplify the task of writing the tutorials on how to use the packages, etc. > For example the PEAR system uses XSL sheets > exclusively, while we are just > in the testing phase of converting to XSL sheets, > and still use DSSSL ones, > which require completely different conversion > tools... > > Goba ===== --- Jesus M. Castagnetto <[EMAIL PROTECTED]> __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
