> 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
-- PHP Documentation Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
