[RkWard-devel] Ideas for the RKWard's website

[Thomas Friedrichsmeier]

Hi Yves, 

that's a pretty well thought out plan. Here are a few thoughts / comments:

B.I introduction
Don't forget to include the "Hosted by Sourceforge"-logo required by SF.

B.II.2 Screenshots
I'm not sure whether you imply that all screenshots are stored in the 
sourceforge screenshot database. If so, I think this may not be a good idea 
at this time, as SF places certain restrictions on those screenshots. Most 
importantly, only six screenshots are allowed per project and no images may 
be larger than 640*480 (http://sourceforge.net/docman/?group_id=50231).
If you're just saying that we shoud make sure to keep up-to-date screenshots 
in the SF screenshot database, I agree, but for the main website I think we 
need more flexibility.

B.II.5 Documentation
Once again, it is good to keep documentation in the SF DocManager, but I think 
it may be too inflexible to be used as our primary store of documentation. 
For one thing, it only accepts HTML docs...

B.V.4 Add news
I don't think we'll need different categories of news anytime soon, as news 
volume is rather low. Of course it might still be good to design the database 
so this can easily be added at a later point of time. In that case I'd 
propose to split up the "level" field into two fields: "level" and 
"category", where "level" would one day mark the significance of the news 
item and category the content (releases/plugins/development plans...).

C.II Technical part
I'm not quite sure whether the naming convention you propose would be the 
files directly given in the URL or only an internal convention. Just to be 
sure, some thoughts on the first:
None of my own attempts at creating mulitlanguage websites have ever proved 
quite elegant. However, I do think using the x_language.php filenaming 
convention may not be the best idea. For instance, using this framework it's 
difficult to have single pages default to a different language (e.g. one page 
in the FR-translation, which is not yet translated, and should therefore be 
displayed in english instead). If in a translation a new page becomes 
available, or an old one is out of date, you would need to fix up all links 
pointing to this page.
Instead a think a smarter mechanism would be to have just one URL for all 
languages with an additional GET-parameter, e.g.:

http://rkward.sourceforge.net/overview.php?lang=FR
or
http://rkward.sourceforge.net/overview.php/?lang=FR (see below)

It would then be the responsibility of overview.php to include the correct 
translation - if available. Also, if the lang-parameter is not given, we 
could use some magic to figure out the best language available based on the 
users preferences set in the browser.

C.IV Pages
One of the things we should consider IMO when redesigning the web-pages, is to 
use a slightly more elegant approach that does not require us to write all 
those dummy .php files. One solution I once came up with and still kind of 
like goes roughly like this:

in .htaccess redirect all directory indexes to a (single) special handler:
DirectoryIndex /handler.php

In this handler we figure out, which directory we're really in (parsing the 
request URL) and then include template, contents, and potentially some 
control files. What this means is that for each page we will have a separate 
directory. The directory layout on disk is identical to the one served (i.e. 
no database lookup, http://rkward.sf.net/devel/somesection/somepage/ will 
really be kept in htdocs/deve/somsection/somepage/). Access to non-existing 
directories get the usual Apache-handling (generating a 404) automatically. 
Also, by specifying not the directory, but a particular file in the URL, the 
handler.php will be bypassed (very practical, e.g. for serving PDF and 
image).
I can send you some code I already have for this (I'll have to clean up some 
project specific stuff first, however). However I have not implemented a 
mechanism for translations in that project, yet (should be quite doable).


Ok, this is a lot of comments. But apart from these things I really like your 
proposal, and I think it will make the rkward-website a LOT better than it is 
today.

Thomas