With all due respect, the ideas are nice, but IMO it will only cause a
lot of work while there is no direct benefit from it. I think it will be
impossible to maintain.
Well, I think it is not a huge task to program. The language preference code is just a few lines ;) We need a page to set it listing the languages, and we need a cookie to store it.
The core offer of My php.net would be to set the preferred
language [PL from now], and the preferred mirror site [PM].
That would be a nice thing, and not much work, but remind the KISS
principle: Keep It Simple Stupid. ie, only have a cookie for the
prefered language, and one for the prefered mirror.
If we serialize the value to a cookie, then it is extendable. And we won't have too much settings I guess, but more then two... Having more cookies will complicate things more. We can have a handler code in prepend.inc (which is included on *all* pages) to put the deserialized settings to _COOKIE :), so they will appear as cookies ;)
Therefore I thought about making php.net the mirror redirection server.
This means that if you would like to access a page on php.net but you
have a different [PM] set, then you are redirected to that
site instead. That would drive much traffic off php.net again :)
But will be terribly annoying if the mirror is not working correctly.
This is only a nice idea if it can be circumvented in an easy way.
Yep. Any ideas ? :)
We can add more settings in the future, as these two core ones are added
and work ;) Some ideas:
- Default bug email address to submit bugs with
Please no, this will only encourage reporting 'bugs'. If people think
they found a bug they can fill their email address.
ACK.
Actually they don't need to look the same, but they need to use the same
HTML
code. We can add JS parts to work with the preference cookie in JS, and do
something differently, eg. drop out the left side manual toc using client
side DOM. We can also include a JS file on the top using <script>, and put
all the user depandant things there, so the PHP page output can be cached,
while that JS will be outputted from PHP with non-cache headers.
This is something for the far future, and I think some of you won't
be too keen on the idea, so this is also up for discussion...
No funky jabbascript please, as there are people who use lynx for
reading the manual.
ACK. Much less work without this ;) I really have not thought that this workaround is a serious option. I can only think about this workaround, and nothing else, and this is not workable, so I gues spages won't look differently for users due to caching.
Goba