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
Seems like you were unable to understand my desire for both language and project indexing, and Davey is not acting on providing a design, so I have started to put effort into cleaning your code up. There was/is a lot to remove and improve. Check what I have done with the general include file, and compare it with the previous version.
Since it is a major rewrite, it will not work with the other codes anymore, so I have only modified the index file to see how the output is presented now. But the site does not seem to get updated from cvs (or it will get updated later?).
BTW we are going to remove the gtk,pear,smarty specific favicons, css files, etc. to clean stuff up, and since you said you are going to experiment with the PEPr system, and you generally like how it works, the RFC stuff should also go. Or do you have a different opinion Mehdi?
Goba