> > > is there any chance that we can revert this annoying feature? > > > The translated documentation is always behind and partly lacks > > > important information from the english version. I want to read > > > the documentation in english (and I am not the only one). This > > > is only possible if I change the url after all searches to /en/ > > > The site should at least be so intelligent to search in the > > > /en/ part of the manual if I search from an /en/ page. > > > > This is fixed now, and works again the way it was before the > > weekend (if you explicitly specify a language with being on a > > manual page in a language, or using the search page with a language > > parameter, that language is carried on). > > > > We do have language specification abilities in URL shortcuts, which > > is the short term solution, while I (or someone else) add the > > language cookie support. See http://php.net/urlhowto > > I remember adding a cookie before for something trivial (user-configurable > css) and jimw pointing out that it tends to do silly things with caching... > (ie, renders it useless)
Adding a cookie for langauge preference is the same as using the user's accept-language header from the technology and caching perspective. I have thought out the whole caching problem, and written down in my my.php.net proposal. You can find it in the archives (news.php.net). Basically if the setting does not modify the pages HTML code, there is no problem with it. This is the case with a language setting cookie, and the accept-language. If we would like to provide CSS selection, the way to go is to have a <link rel="stylesheet" href="/style.php" /> at the top, and print out stylesheets without caching (or cookie dependant caching) from that page. This would make pages have the same HTML code, but with different user based CSS files. Anyway, we do not have any CSS preference plans, do we? Goba -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
