OK, here is the first organizational decision. We have a matrix with projects and languages. Some projects have no languages at all (Livedocs and PECL will not have language specific info). These projects however need to have their howtos (how to set up livedocs, where are PECL extensions documented, etc). So these projects need special files.
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?
hu.docs.php.net, pear.docs.php.net, hu.pear.docs.php.net (or pear.hu.docs.php.net) should pick up the pages and navigation elements relevant for that selection from the matrix.
Since we have livedocs as project on the website, the first idea actually used on keliglia.com will need to be changed. I'm now thinking
about having : PROJECT.docs.keliglia.com/part/LANG*, LANG being optional (Nuno, happy ? ;)). As projects, we'll have :
php
pear
smarty
gtk
livedocs (or live to have live.docs.php.net ;))
I don't think so that putting the project into the domain and the language into the path is a good solution. As I have outlined above, I would like to get everything related to Hungarian efforts, or PEAR efforts or just the Hungarian PEAR efforts. IMHO it would be diserable that one picks a row, a column or a cell from the matrix (or the whole matrix, which is the homepage).
We aim at helping those who would like to work on PEAR stuff, but would help translations too, and those who would like to work on French stuff on all projects (but not with other languages). So there are possible valid use cases for picking a row or a column from the matrix.
So we need a projects and languages relation array as you suggested and functions to access projects for a language and languages for a project. that would enable us to go into a row or a column of the matrix. Then the projects should have capabilities (revcheck, RFC, etc.) as you outlines. Beware that there are probably going to be pages for projects in a particular language (information for Hungarian PEAR documentation contributors). Or at least the system should be ready to handle these. These could be handled as capabilities (like revcheck and RFC handling), and can be selected from the matrix on a per project and/or per language basis.
function main()
{
global $PROJECTS_AND_LANGS;
list($vhost, $lang) = get_asked_vhost_and_lang_with_magic_stuff();
if (isset($PROJECTS_AND_LANGS[$vhost])) {
define('PROJECT', $vhost);
if (isset($PROJECTS_AND_LANGS[$vhost][$lang])) {
define('LANG', $lang);
} else {
define('LANG', 'en');
}
} else {
define('PROJECT', 'www');
define('LANG', 'en');
}
}
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.
We also can implement a function to generate a bash include file (and even add its name in .cvsignore to be completely happy).
It would be nice. In an ideal world, we should only have config data (supported languages and their metadata) at one place.
Goba