Hacking around like this seems liable to break something or not work in some case. I think a cookie would work better than a uselang hack. It would also look better to users.
On Fri, 29 Jun 2012 07:08:40 -0700, Daniel Werner daniel.werner@wikimedia.de wrote:
Just stumbled over the "GetLocalURL::Internal" (http://www.mediawiki.org/wiki/Manual:Hooks/GetLocalURL::Internal) hook which was introduced in MW 1.19. This works pretty fine, just doesn't work for page content but that can be done with the linker. It works for pretty much everything else though, e.g. sites nav and tabs on top of the page.
I am not sure though whether this is breaking anything. Putting it in there is pretty deep, so whenever an url is requested from any title object, the "uselang" parameter is attached to it. Seems to work fine so far.
Cheers Daniel W.
2012/6/27 Platonides Platonides@gmail.com:
On 27/06/12 11:43, Denny Vrandečić wrote:
2012/6/26 Platonides Platonides@gmail.com:
On 26/06/12 18:48, Denny Vrandečić wrote:
We tried to change the linker in order to add the uselang parameter every time -- but it only works in the content, not in the sidebar and actionlinks.
We could put the language into a cookie, as the ULS currently does, but this means that the squid caches won't work, afaik.
You are going to fragment the caches whether you use a parameter or a cookie. IMHO the cookie option is a cleaner one (I think that would also allow to make a single purge).
We thought about using the uselang only if it is not the main used language (i.e., usually en), which means the caches would kick in 40% of the time at least.
You mean serving other language directly from the apaches? Could be done. But would they support a 50% of the squid load?
The cookie thing wouldn't have such a convenient default AFAIK, but I might be really easily wrong here.
I think it could be done both ways. If the page is cacheable, the squid/varnish would store the page with the cookie value, and then serve it only for those request with the same cookie value.
We could take the output just before it is send to the browser and regex-substitute all the links in order to add the uselang parameter every... OK, half joking. Only half.
Some wikis have a javascript which does exactly that, adding a userlang parameter the moment you click a link. Much better than a string regex :)
But only working if JavaScript is available.
Sure, that's the limitation :)
You would still cover almost everyone but jidanni ;)
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l