Re: A complete summary of doc.keliglia.com status

From: Date: Sat, 12 Jun 2004 15:49:18 +0000
Subject: Re: A complete summary of doc.keliglia.com status
References: 1 2 3 4  Groups: php.doc.web 
Request: Send a blank email to doc-web+get-73@lists.php.net to get a copy of this message
mmm, I'm not sure about PECL being a part of this site. Wasn't we about to document it in phpdoc ?
Right. But those visiting the site will not surely know. Where to turn to if I am interested in where should I put the documentation for my PECL extension. I just go to docs.php.net. But if there is no PECL option, I will think that the site does not deal with it. We need the PECL and Livedocs parts to explain what are those, and where are those connected into the big picture. These are the buzzwords connected to the PHP and our documentation which should have a primary spot. PECL will probably only have a page explaining that the documentation is in phpdoc (and also in peardoc for a small transitional period). The PECL page might also list extensions and provide links to their related stuff elsewhere on the site. The Livedocs page will probably have some introduction on what is that, how is that connected to the project, how can one set it up, etc. These will not need some of the features of the site (revchecks), but might need some others. RFCs about livedocs?
Ok for PECL, it's more clear now :) And if one day, we decide to have a separated manual for PECL, it will be easy to change it to a "standalone" project. I was also thinking about an rfc part for livedocs with the ability to vote for proposals, and maybe a manual part too to have a complete manual (rendered with livedocs) for livedocs with the informations you suggested like credits, installation (a loooot of foreign people are struggling to set it up. Having the information translated can help) [snip]
This would be fine except that you expect people to select one project always. This does not fit to the 'translator who is interested in all projects' use case.
Thinking about this, we shouldn't matter about the language + project relation when defining our constants, but only when rendering the navigation bars. I mean, for smarty for example, there's no hungarian translation. But if someone asks for hu.smarty.doc.k.com I think we shouldn't take care about this, default to the english page and have a little info box like "Hi, what about translating smarty docs in hungarian ?" But, when generating the navigation, we should have the project/language availability information. We shouldn't link to unsupported translations when navigating a project, and shouldn't link to unsupported projects when navigating through a language. Please have a look at : http://hu.live.doc.keliglia.com/dummy/ http://hu.doc.keliglia.com/dummy/ http://doc.keliglia.com/dummy/ http://fr.bogus.doc.keliglia.com/dummy/ http://too.many.parameters.fr.live.doc.keliglia.com/dummy/ and tell me if it's okay with you didou

« previous php.doc.web (#73) next »