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

Wed May 11 08:24:41 UTC 2005

Le Mardi 10 Mai 2005 21:05, Thomas Friedrichsmeier a écrit :
> Hi Yves,
>
> that's a pretty well thought out plan. Here are a few thoughts / comments:
thanks :-)
>
> B.I introduction
> Don't forget to include the "Hosted by Sourceforge"-logo required by SF.
Yes, I did not write it but  know that. I will update the doc.
> 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.
Ok, I did not know this limitation. Actually it was the problem for me. I did 
not know if we use the sourceforge system or not.
>
> 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...
Ok, I saw that yesterday to publish the doc, so I changed some part of the 
doc, but not all !
> 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...).
Ok, so  do it, bt we do not use it until we need it ! No problem it is not a 
big work.
> 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. 
You right, I thought it was interesting but it is bigger work !
> 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.:
Yes, it is what i want to do !
>
> http://rkward.sourceforge.net/overview.php?lang=FR
This is what i wanted to use.
> or
> http://rkward.sourceforge.net/overview.php/?lang=FR (see below)
I do not know this kind of URL :-(
> 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.
Great ! But I do not know how to do that. I ma looking for that !

>
> 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
Here I am a little bit lost. I am not a profesionel in PHP, I have only basic 
knowledge. That's why I choose a simple structure.
> 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. 
If I understant is that all page are redirected to handler.php in a directory 
by the .htacess file. The the php code use the URL to know where to find the 
content (directory and subdirectory) ?
> 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/devel/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).
Here you mean that if the URL contains a PHP file, it is not redirected to 
handler.php ?
> 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).
Yes, if it is not too much work !
>
> 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.
Thanks for your coment, I know more about what you attemp for.

Y.
> Thomas
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> RKWard-devel mailing list
> RKWard-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/rkward-devel

-- 
Yves Jacolin
yjacolin at free.fr

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.0 (GNU/Linux)

mQGiBEJffGYRBACn/9+UiayxI2EICc6xmfWXOdktQ7IEBVRml4lnXj715fDS8tzv
ylGfAt8m48NEXow75Pc9Oi8ftiwhEjEOoo7l9N5nFS4vL3C7AB23SizoNV4PXTTQ
Nfzle5DwmBm2DgXnsslpnXykTNT5vWi6hxix2jGnz0wSKoh+ZA3A+ubIPwCg1WML
GDAM9pIt1mOJiFwwBljpcqsD+gIn/ScXAjLeoZeQxKX+0m3vY1y0IJBrQFbpwdZs
/+CCMnQuc6gjnK8AspPWtzBnbqTFfE2xLezSHv2Plwc2l61izgrioP5QSK7BuorK
krFebWid4FuW2xxMTTuPr8zveJhByO8NgZ6fxfHxwzjW4y3CGmLJH7ZgmqrqlHBO
uZgtA/9EVseoqpacd2G/tJ7dnkfrglHXv0A5y2tMfinpTZXdQFMwK8C/i1rzVz9R
edUluBAHbcB+BoeMun6WuOoDytemr+Hooqe1aqLJ2Sf9nZDJFGuY08gsSdCZi/Sx
wX6JpMwWLKXpl/cK1NpVOvkjikRAIQP8hpTjwoNzY+nyiUzAgLQaSmFjb2xpbiA8
eWphY29saW5AZnJlZS5mcj6IWwQTEQIAGwUCQl98ZgYLCQgHAwIDFQIDAxYCAQIe
AQIXgAAKCRCKzn2vRDmnBdgSAKDIoaWpZqV8lMDfUBndpV/ugfu4SACdEe8x2kOx
jdYh223q/ixW5xxqGU+0GkphY29saW4gPHlqYWNvbGluQGZyZWUuZnI+iF4EExEC
AB4FAkJffKICGyMGCwkIBwMCAxUCAwMWAgECHgECF4AACgkQis59r0Q5pwVvfACg
0mLGCC+DUrJW66vQqajPtBuIjhIAnjH1CZV8NIh7IjbcVEevgQCK0jSQuQENBEJf
fGcQBACOOw+UQV2BCIEq6oxizD6ka8Un8hybrmGxF7MwQSZvtCSLAtAC7gd0vbjX
pAecxTelEi37SNQSvt0l0CQhQvwWLGXSEig7mNiWk3D9cQRN8JFauSmk7YxVo62k
3iFU17M0wUiqRdpe18zL8euhg8WHKyuWfXSBAt3/u8ZkQZHPLwADBQP7Bl0y4O/L
mSaMfh8rG0vnMHqwAhlTIgDtwk9exQr0ZD5baqvuzCOqEyQFHzG5q3EJj2gAQkd1
mIi9wTXvpOKPuIBSiCGxsc3vUclOgICQA22X9tvM7frZyQEeXlSfAbl8uQIYdqQ8
8XCaHP7Pijk2HiTitg00dFojQj35dBRQjTSIRgQYEQIABgUCQl98ZwAKCRCKzn2v
RDmnBWzFAJ9pQA5j0ps6/NCZye8tFpR/oHE/EQCg0HPXI5AUaGnEDR5WTp4aA3W4
MHk=
=5guA
-----END PGP PUBLIC KEY BLOCK-----