Hello,
in the last few months and years the Uzbek Wikipedia has shown promising growth, and it is turning into a potentially relevant source of knowledge for the Uzbek people.
But due to a technical 'glitch', access to the Uzbek Wikipedia in Uzbekistan via the HTTP protocol is for some reason redirected to msn.com.
The same is not true for the HTTPS protocol, and also for all other language editions.
The glitch is not with the WMF infrastructure, but with providers in Uzbekistan. Requests by community members to the providers and official agencies have been met only with silence, there is no official statement or recognition about this.
We discussed both with search engine providers and Wikimedia developers if there is a way to resolve this issue, and there is: by making the HTTPS version of the Uzbek Wikipedia canonical the search engines would list the HTTPS version in the search results, thus circumventing the glitch. As far as I understood the technical folks at Wikimedia this can be done with a small amount of effort.
Using HTTPS would have the additional advantage of a higher level of anonymity and privacy of Wikipedia editors from inside Uzbekistan.
There is a risk with that, though: it could be that the glitch will suddenly extend to HTTPS too, and this would cover all language editions of Wikipedia, not only the Uzbek one. This would raise the issue to more visibility too, and one could hope that it would get resolved then. But just to make it obvious: the action proposed here could escalate the issue. It could resolve it, but this is not necessarily the case.
There have been some discussions within the Uzbek Wikipedia community, and as far as I can tell there is consensus that the step suggested here should be taken, but there is no visible account of this consensus that I can link to, and that is probably to the better for those involved. The Foundation asked to have this discussion on this mailing list, and to reach a decision here about this step.
The question this list would need to find agreement on is: should the Uzbek Wikipedia be set up in a way that makes access via the HTTPS protocol the canonical one?
For Uzbeks at home it is not possible to access Wikipedia in their native language. Whereas in the big cities that is not so much of an issue, as most people speak Russian, this is decreasingly true for the towns and villages of the country. I think it is fair to say that it is part of our mission as the Wikimedia movement to provide these people with access to the sum of human knowledge too.
Warmest regards.
P.S.: Yes, this is a sock puppet mail account, as I prefer my name not be widely visibly associated with this measure due to private reasons. For the same reasons I might have slipped in an euphemism or two in this mail.
If, as I'd think, switching to HTTPS only is only a matter of a rather simple configuration change (for a wiki like this that doesn't impact load much), and has even a small chance to help in such an unfortunate situation, then it should be done as soon as possible IMHO.
Nemo
"Federico Leva (Nemo)" nemowiki@gmail.com schrieb:
If, as I'd think, switching to HTTPS only is only a matter of a rather simple configuration change (for a wiki like this that doesn't impact load much), and has even a small chance to help in such an unfortunate situation, then it should be done as soon as possible IMHO.
Apache allows virtual server config based on the used URL. Maybe one of Wikimedia's IP addresses could be used to show the Wikipedia in Uzbek? IMHO it is just a question of time, until https will also be redirected.
Is it also be possible, that this is a cracker's work and not that of the ISP?
Marco
On 23/12/12 22:15, Anonymous User wrote:
We discussed both with search engine providers and Wikimedia developers if there is a way to resolve this issue, and there is: by making the HTTPS version of the Uzbek Wikipedia canonical the search engines would list the HTTPS version in the search results, thus circumventing the glitch. As far as I understood the technical folks at Wikimedia this can be done with a small amount of effort.
Is it enough to set the <link rel="canonical">, or is it also necessary to redirect?
Either way, the Squid cache would have to be purged, then the search engines would have to reread that site.
-- Tim Starling
On Mon, Dec 24, 2012 at 1:15 AM, Tim Starling tstarling@wikimedia.org wrote:
Is it enough to set the <link rel="canonical">, or is it also necessary to redirect?
When I asked the nice folks at Google's search team, they answered me the following:
* The best answer would for them to use rel=canonical tags so that http://example.wikimedia.uz points to http*s*://example.wikimedia.uz. So I'd send them this page: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394 and tell them to start doing that. If they're very serious (and it's a small property, so there's not much risk) then they could make every http page 301 to the https version as well.
I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be "very serious", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel="caonical" would already be really, really helpful.
Thank you all for your encouraging comments so far.
Dear all,
thank you again for your answers so far. I would have had hoped to have more voices participating, but everyone who did agreed that it should be done.
If you want to state your opinion -- whether support or worry -- on setting HTTPS canonical for the Uzbek Wikipedia, please do so. I am sure it will support the Foundation in making the right decision.
All the best greetings.
On Mon, Dec 24, 2012 at 10:23 AM, Anonymous User wikifriend2001@gmail.comwrote:
On Mon, Dec 24, 2012 at 1:15 AM, Tim Starling tstarling@wikimedia.org wrote:
Is it enough to set the <link rel="canonical">, or is it also
necessary to redirect?
When I asked the nice folks at Google's search team, they answered me the following:
- The best answer would for them to use rel=canonical tags so that
http://example.wikimedia.uz points to http*s*://example.wikimedia.uz. So I'd send them this page: http://support.google.com/webmasters/bin/answer.py?hl=en&answer=139394 and tell them to start doing that. If they're very serious (and it's a small property, so there's not much risk) then they could make every http page 301 to the https version as well.
I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be "very serious", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel="caonical" would already be really, really helpful.
Thank you all for your encouraging comments so far.
On 27/12/2012 5:54 AM, Anonymous User wrote:
thank you again for your answers so far. I would have had hoped to have more voices participating, but everyone who did agreed that it should be done.
I think this is the closest I've ever seen to "universal support" on Wikimedia-l ever. :-)
-- Coren / Marc
On 12/27/2012 10:46 AM, Marc A. Pelletier wrote:
On 27/12/2012 5:54 AM, Anonymous User wrote:
thank you again for your answers so far. I would have had hoped to have more voices participating, but everyone who did agreed that it should be done.
I think this is the closest I've ever seen to "universal support" on Wikimedia-l ever. :-)
-- Coren / Marc
So, I just asked Chris Steipp (WMF engineer in charge of software security) for his thoughts on this:
I can add a, "I think it's a good idea" to the list, but Ops will need to be ok with the shift. I don't think it would be a problem, but it does mean google spidering our https site, and that may concern them. I think ops would also be the ones to implement the actual change.
So in my opinion we can move discussion over to https://bugzilla.wikimedia.org/show_bug.cgi?id=43466 ("when serving Uzbek Wikipedia, make HTTPS canonical"). I've asked a bug wrangler to contact Ops about it as well.
On 12/27/2012 03:08 PM, Sumana Harihareswara wrote:
So in my opinion we can move discussion over to https://bugzilla.wikimedia.org/show_bug.cgi?id=43466 ("when serving Uzbek Wikipedia, make HTTPS canonical"). I've asked a bug wrangler to contact Ops about it as well.
(Maybe I should just include a link to https://meta.wikimedia.org/wiki/Glossary in every email I send because I do use a lot of jargon! Sorry about that.)
On 24/12/12 20:23, Anonymous User wrote:
I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be "very serious", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel="caonical" would already be really, really helpful.
This is done now. It would be good if Google could crawl uz.wikipedia.org to update the canonical URLs.
In case anyone is wondering, I don't think this would be a good thing to do on zh.wikipedia.org. The Chinese government would happily block *.wikipedia.org port 443 if it became popular. At least the current situation provides a way to work around keyword filtering for people who are sufficiently motivated -- if HTTPS was blocked, it would be much less useful.
-- Tim Starling
Le 07/01/2013 06:17, Tim Starling a écrit :
On 24/12/12 20:23, Anonymous User wrote:
I don't know how much effort each of these two measures would be. If you'd ask me, I would suggest to be "very serious", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel="caonical" would already be really, really helpful.
This is done now. It would be good if Google could crawl uz.wikipedia.org to update the canonical URLs.
In case anyone is wondering, I don't think this would be a good thing to do on zh.wikipedia.org. The Chinese government would happily block *.wikipedia.org port 443 if it became popular. At least the current situation provides a way to work around keyword filtering for people who are sufficiently motivated -- if HTTPS was blocked, it would be much less useful.
I have released last week a ZIM file of the Wikipedia in Uzbek to make it available offline.
This is a pretty poor replacement for the online Wikipedia, but in some cases this may help people accessing our contents.
Everything is on the Kiwix homepage http://www.kiwix.org.
Bundle with Kiwix: http://download.kiwix.org/portable/wikipedia_uz_all.zip.torrent
Kind regards Emmanuel
Dear all, dear Tim,
I want to extend the "thank you" from the Uzbek Wikipedia community. I let them use their own words (although, translated for the benefit of this list).
user 1: wow, it's great! who has done it user 2: wikimedia programmers user 1; super! real heroes! user 3: thank you, thank you, thank you! user 4: so now we're waiting for google to index uzwiki user 2: it's awesome, i cannot even express how awesome it is user 2: Thank you guys for helping us. And special thanks to Tim Starling. user 2: We're going to introduce Tim Starling day in Uzbek Wikipedia as well
I also pinged my contacts at Google, hoping that they can schedule the reindexing soon. Thanks to everyone involved.
Rahmat va salomlar!
On Mon, Jan 7, 2013 at 6:17 AM, Tim Starling tstarling@wikimedia.orgwrote:
On 24/12/12 20:23, Anonymous User wrote:
I don't know how much effort each of these two measures would be. If
you'd
ask me, I would suggest to be "very serious", but we are not under a deadline (the situation has been like this for more than a year now), and setting the rel="caonical" would already be really, really helpful.
This is done now. It would be good if Google could crawl uz.wikipedia.org to update the canonical URLs.
In case anyone is wondering, I don't think this would be a good thing to do on zh.wikipedia.org. The Chinese government would happily block *.wikipedia.org port 443 if it became popular. At least the current situation provides a way to work around keyword filtering for people who are sufficiently motivated -- if HTTPS was blocked, it would be much less useful.
-- Tim Starling
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l
wikimedia-l@lists.wikimedia.org