Hi all,
we are trying to let users switch their language - whether they are logged in or not - through a language selector. This can be either the ULS, which is progressing impressively, or just a list of languages in the sidebar, or anything else. After selecting it, the page is rerendered using the uselang parameter.
Now the problem: the uselang parameter is not sticky. When I move to another page, it is lost.
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.
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.
Another solution could be to put the language into the path, i.e. the pretty URL /wiki/San_Franicisco does get rewritten to /w/index.php?title=San_Francisco as of now, but change that to /hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr
(or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this is more pleasing)
I think this is based on an idea of Brion during the Hackathon.
So switching the user language amounts to change the URL.
Any comments on this?
Cheers, Denny
On 26/06/12 18:48, Denny Vrandečić wrote:
Hi all,
we are trying to let users switch their language - whether they are logged in or not - through a language selector. This can be either the ULS, which is progressing impressively, or just a list of languages in the sidebar, or anything else. After selecting it, the page is rerendered using the uselang parameter.
Now the problem: the uselang parameter is not sticky. When I move to another page, it is lost.
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 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 :)
Another solution could be to put the language into the path, i.e. the pretty URL /wiki/San_Franicisco does get rewritten to /w/index.php?title=San_Francisco as of now, but change that to /hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr
(or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this is more pleasing)
I like having the structure of languages-as-folders but you would need to send a purge to every language variation of a page...
I think this is based on an idea of Brion during the Hackathon.
So switching the user language amounts to change the URL.
Any comments on this?
Cheers, Denny
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. The cookie thing wouldn't have such a convenient default AFAIK, but I might be really easily wrong here.
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.
Another solution could be to put the language into the path, i.e. the pretty URL /wiki/San_Franicisco does get rewritten to /w/index.php?title=San_Francisco as of now, but change that to /hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr
(or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this is more pleasing)
I like having the structure of languages-as-folders but you would need to send a purge to every language variation of a page...
True.
Thank you for the comments, Platonides!
Cheers, Denny
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 ;)
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
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
26 Июнь 2012 г. 20:56:14 пользователь Denny Vrandečić (denny.vrandecic@wikimedia.de) написал:
Hi all, we are trying to let users switch their language - whether they are logged in or not - through a language selector. This can be either the ULS, which is progressing impressively, or just a list of languages in the sidebar, or anything else. After selecting it, the page is rerendered using the uselang parameter. Now the problem: the uselang parameter is not sticky. When I move to another page, it is lost. 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.
I've developed such extension back in 2009 when started to work with MediaWiki. I used: 'SkinTemplateBuildNavUrlsNav_urlsAfterPermalink' hook to add sticky uselang value to sidebar links. It was long time ago. Don't know whether that will work with Vector.
We could put the language into a cookie, as the ULS currently does, but this means that the squid caches won't work, afaik. 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.
Another solution could be to put the language into the path, i.e. the pretty URL /wiki/San_Franicisco does get rewritten to /w/index.php?title=San_Francisco as of now, but change that to /hr/San_Francisco rewritten to /w/index.php/San_Francisco?uselang=hr (or /w/index.php/Special:UseLang/hr/San:Franciso with an Alias if this is more pleasing) I think this is based on an idea of Brion during the Hackathon. So switching the user language amounts to change the URL. Any comments on this?
It would be nice if the language code was the base of directory in URL path. Then it may be extracted by Router. That thing is not only about persistently switching language "on the fly". It's also about making multi-lingual wiki's without multiple virtual hosts and without interwiki links. Which is nice thing for non-English sites (eg. our university site has English and Russian version of the page and they did not want to have en.* and ru.* domains for that). There were some problems with uselang, so I've made different setup: virtual hosts based on URI's virtual directory: site.org/en/Page site.org/ru/Page much as you suggested, parsing URI in LocalSettings.php. And real interwiki hosts with "commons" to share files. It wasn't made online due to extremly low budget, however. Dmitriy
2012/6/27 Dmitriy Sintsov questpc@rambler.ru:
26 Июнь 2012 г. 20:56:14 пользователь Denny Vrandečić (denny.vrandecic@wikimedia.de) написал: 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.
I've developed such extension back in 2009 when started to work with MediaWiki. I used: 'SkinTemplateBuildNavUrlsNav_urlsAfterPermalink' hook to add sticky uselang value to sidebar links. It was long time ago. Don't know whether that will work with Vector.
Thanks, we'll investigate that.
Cheers, Denny
On 26/06/12 18:48, Denny Vrandečić wrote:
Now the problem: the uselang parameter is not sticky. When I move to another page, it is lost.
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.
Just to add that variant parameter worked this way for a while, so it could be looked up how was that achieved.
2012/6/27 Nikola Smolenski smolensk@eunet.rs:
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.
Just to add that variant parameter worked this way for a while, so it could be looked up how was that achieved.
I was thinking to ask you about this: when I select latin variant on sr.wp as a non-logged in user, it is not sticky, right? Even though you have a nice sr-el path, it does not get propagated?
Or am I missing something?
Cheers, Denny
On 27/06/12 12:43, Denny Vrandečić wrote:
2012/6/27 Nikola Smolenskismolensk@eunet.rs:
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.
Just to add that variant parameter worked this way for a while, so it could be looked up how was that achieved.
I was thinking to ask you about this: when I select latin variant on sr.wp as a non-logged in user, it is not sticky, right? Even though you have a nice sr-el path, it does not get propagated?
It used to be sticky, it isn't now. Same for Chinese Wikipedia.
Hi Denny,
Op 26-6-2012 18:48, Denny Vrandečić schreef:
<knip>
Any comments on this?
Did you already take a look at how this was implemented on Commons? Mdale and I hacked up a first version a couple of years ago in Paris and Timo later improved this. Code is now at https://commons.wikimedia.org/wiki/MediaWiki:AnonymousI18N.js and loaded from https://commons.wikimedia.org/wiki/MediaWiki:Common.js
Maarten
wikitech-l@lists.wikimedia.org