Re: [Wikitech-l] Planning for the future: prepare high resolution icons and images in your code
On Tue, Jun 19, 2012 at 5:19 AM, Brion Vibber br...@pobox.com wrote: On Mon, Jun 18, 2012 at 4:43 PM, Platonides platoni...@gmail.com wrote: My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth. That's really a separate issue, which is that a large portion of image uses in content should probably be changed; trade hardcoded sizes for galleries and priority markers, perhaps. And of course replace the crappy old link-to-image-page with a sensible click-to-zoom. I had once talked about this (click-to-zoom) feature on wikimedia sites in irc. Wikipedia could have something similar to sites like Facebook or Google+ where the images float over the page. I have tried an extension FancyBoxThumbshttp://www.mediawiki.org/wiki/Extension:FancyBoxThumbs which enables such a feature, with some enhancements it can be more awesome. -- Cheers, Nischay Nahata ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Planning for the future: prepare high resolution icons and images in your code
On Tue, Jun 19, 2012 at 1:43 AM, Platonides platoni...@gmail.com wrote: My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth. This is a concern seam carving planned to solve if we read or see again the original paper/video: http://www.faculty.idc.ac.il/ARIK/site/seam-carve.asp Would it be useful to do seam carving in addition to rescaling or do you think it's not realist to request images contributors to test and when needed configure a seam carving mask on their picture? -- Sébastien Santoro aka Dereckson http://www.dereckson.be/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Wikipedia search for Firefox?
Chris Peterson wrote: hi, I'm a developer at Mozilla and I have a patch [1] that would switch Firefox's Wikipedia search box from HTTP to HTTPS. Hello Chris, I have forwarded your mail to the Wikimedia operation team. They should be able to give you a clear answer. If you do not hear from anyone, I am volunteering to get bugged until you get an answer :-] cheers, -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 3 million null edits
Hi guys, There must be an alternative for https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#3_million_null_edits right? But what is it? Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 3 million null edits
How did this not propagate in the usual way through the job queue? (And why wouldn't either a null or an insignificant edit to the template add the requisite job queue entries now?) A. Στις 19-06-2012, ημέρα Τρι, και ώρα 10:00 +0200, ο/η Maarten Dammers έγραψε: Hi guys, There must be an alternative for https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#3_million_null_edits right? But what is it? Maarten ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Wikimedia at Open Source Bridge conference, late June, Portland
June 26-29, a bunch of us will be in Portland, Oregon, USA for the Open Source Bridge conference. http://opensourcebridge.org/events/2012/schedule WMF is sponsoring the Friday unconference day, and will host a hacking table that day as well as (I hope) the Tuesday Hacker Lounge Project/Community Night. Wikimedians are giving several talks during OSBridge: Identity, Reputation and Gratitude: Designing for a community by Brandon Harris: Tuesday, 1:30 A snapshot of Open Source in West Africa by Renaud Gaudin: Tuesday, 3:45 Building A Visual Editor for Wikipedia by Roan Kattouw and Trevor Parscal: Tuesday, 4:45 Internationalization @Wikipedia: Helping add the next billion web users by Alolita Sharma: Wednesday, 10am Why you need to host 100 new wikis just for yourself. by Ward Cunningham: Wednesday, 2:30 Outreach Events: My Triumphs, My Mistakes by Asheesh Laroia and me: Thursday, 3:45 I give the opening keynote address on Tuesday morning. My tentative title: Be Bold. If you're in or near Portland and want to come, let me know; I might be able to hook you up with a free conference pass. -- Sumana Harihareswara Engineering Community Manager Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 3 million null edits
On Tue, Jun 19, 2012 at 11:50:09AM +0300, Ariel T. Glenn wrote: How did this not propagate in the usual way through the job queue? (And why wouldn't either a null or an insignificant edit to the template add the requisite job queue entries now?) The people involved there have been less than forthcoming in their drive to have someone implement their chosen solution, so we don't even know whether there's a real issue where the job queue never updated the pages, or that one template was edited but not others and the people involved don't realize this, or whether it's just that the job queue and a normal action=purge don't update the various links tables (bug 5382) so Special:LinkSearch shows the wrong links. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 3 million null edits
On 19/06/12 10:00, Maarten Dammers wrote: Hi guys, There must be an alternative for https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests#3_million_null_edits right? But what is it? Maarten That probably explains the high thumbnail purge rate detected yesterday. AaronSchulz was wondering who could be the culprit... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] maybe just visiting one will be enough to keep me notified about the rest?
On 19/06/12 03:46, jida...@jidanni.org wrote: I got four mails page Manual:RemoveUnusedAccounts.php has been changed by Sumanah page Manual:LocalSettings.php has been changed by KrenairBot page Manual:Edit.php has been changed by KrenairBot page Manual:GetText.php has been changed by KrenairBot each says There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist. maybe just visiting one will be enough to keep me notified about the rest? No. Maybe it should be rewritten as of further changes to this page unless you visit it. Suggestions welcome. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] maybe just visiting one will be enough to keep me notified about the rest?
Does it matter? They're all one-off emails due to lots of pages being updated to work with Gitweb instead of ViewVC (gitweb doesn't like file paths starting with /). In future, I suggest you tick 'Hide bot edits from the watchlist' on the Special:Preferences Watchlist tab. Krenair On 19/06/12 02:46, jida...@jidanni.org wrote: I got four mails page Manual:RemoveUnusedAccounts.php has been changed by Sumanah page Manual:LocalSettings.php has been changed by KrenairBot page Manual:Edit.php has been changed by KrenairBot page Manual:GetText.php has been changed by KrenairBot each says There will be no other notifications in case of further changes unless you visit this page. You could also reset the notification flags for all your watched pages on your watchlist. maybe just visiting one will be enough to keep me notified about the rest? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Wikipedia search for Firefox?
On Tue, Jun 19, 2012 at 3:39 AM, Chris Peterson cpeter...@mozilla.com wrote: hi, I'm a developer at Mozilla and I have a patch [1] that would switch Firefox's Wikipedia search box from HTTP to HTTPS. Who would be an appropriate technical contact at Wikimedia that I can coordinate with? Is this a change Wikimedia would welcome? Or would the increased SSL server load be an undue burden for Wikimedia? Just to be clear, this change would only affect Firefox users who search Wikipedia using Firefox's search box. A few months ago, Mozilla switched Firefox 14 (currently in Beta) to use Google's HTTPS search [2]. If I check in my Wikipedia patch soon, the change would ride Firefox's Nightly, Aurora, and Beta release channels [3] and be released to the general public in Firefox 16 (October 2012). Please don't do so. HTTPS is a new service, and we haven't properly load tested it yet. The first target for production load testing is for logged-in users. I'm not opposed to the change completely, but I'd prefer to let you guys know when we're ready. Thanks, - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Wikipedia search for Firefox?
Thanks, Ryan. When you guys would like Mozilla to make this switch to HTTPS, you can just reopen Firefox bug 758857. chris On 6/19/12 10:35 AM, Ryan Lane wrote: On Tue, Jun 19, 2012 at 3:39 AM, Chris Peterson cpeter...@mozilla.com wrote: hi, I'm a developer at Mozilla and I have a patch [1] that would switch Firefox's Wikipedia search box from HTTP to HTTPS. Who would be an appropriate technical contact at Wikimedia that I can coordinate with? Is this a change Wikimedia would welcome? Or would the increased SSL server load be an undue burden for Wikimedia? Just to be clear, this change would only affect Firefox users who search Wikipedia using Firefox's search box. A few months ago, Mozilla switched Firefox 14 (currently in Beta) to use Google's HTTPS search [2]. If I check in my Wikipedia patch soon, the change would ride Firefox's Nightly, Aurora, and Beta release channels [3] and be released to the general public in Firefox 16 (October 2012). Please don't do so. HTTPS is a new service, and we haven't properly load tested it yet. The first target for production load testing is for logged-in users. I'm not opposed to the change completely, but I'd prefer to let you guys know when we're ready. Thanks, - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Wikipedia search for Firefox?
Hey Chris Could you give us a ballpark estimate of how much search queries you expect per day? Best Diederik Sent from my iPhone On 2012-06-19, at 13:51, Chris Peterson cpeter...@mozilla.com wrote: Thanks, Ryan. When you guys would like Mozilla to make this switch to HTTPS, you can just reopen Firefox bug 758857. chris On 6/19/12 10:35 AM, Ryan Lane wrote: On Tue, Jun 19, 2012 at 3:39 AM, Chris Peterson cpeter...@mozilla.com wrote: hi, I'm a developer at Mozilla and I have a patch [1] that would switch Firefox's Wikipedia search box from HTTP to HTTPS. Who would be an appropriate technical contact at Wikimedia that I can coordinate with? Is this a change Wikimedia would welcome? Or would the increased SSL server load be an undue burden for Wikimedia? Just to be clear, this change would only affect Firefox users who search Wikipedia using Firefox's search box. A few months ago, Mozilla switched Firefox 14 (currently in Beta) to use Google's HTTPS search [2]. If I check in my Wikipedia patch soon, the change would ride Firefox's Nightly, Aurora, and Beta release channels [3] and be released to the general public in Firefox 16 (October 2012). Please don't do so. HTTPS is a new service, and we haven't properly load tested it yet. The first target for production load testing is for logged-in users. I'm not opposed to the change completely, but I'd prefer to let you guys know when we're ready. Thanks, - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Planning for the future: prepare high resolution icons and images in your code
This also concerns me but luckily it's concerning others too. This is an interesting article here about the current state of adaptive images if you haven't read it: http://html5doctor.com/html5-adaptive-images-end-of-round-one/ On Mon, Jun 18, 2012 at 4:49 PM, Brion Vibber br...@pobox.com wrote: On Mon, Jun 18, 2012 at 4:43 PM, Platonides platoni...@gmail.com wrote: My concern are images inside articles, where a big screen user will want |500px but a small screen one |120px. Maybe we should move to a size specification dependant on the clientWidth. That's really a separate issue, which is that a large portion of image uses in content should probably be changed; trade hardcoded sizes for galleries and priority markers, perhaps. And of course replace the crappy old link-to-image-page with a sensible click-to-zoom. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] HTTPS Wikipedia search for Firefox?
On 6/19/12 11:21 AM, Diederik van Liere wrote: Could you give us a ballpark estimate of how much search queries you expect per day? My back-of-the-envelope estimate would be fewer than 10M requests per day. These would not be additional search queries, just requests moving from HTTP to HTTPS servers. My math: I don't have have good numbers regarding Firefox's search box queries, but I saw a Firefox usability report which estimates that only about 8% of Firefox users haved used a non-default search engine (i.e. not Google, but not necessarily Wikipedia) from Firefox's search box. Page [1] says Wikipedia received about 18.0 billion page requests in May. Page [2] says about 22% of Wikipedia requests are from Firefox users. So a very generous upper limit might be: 18B requests/May * 22% Wikipedia users * 8% non-Google Firefox searches = (18,000M / 31 days) * .22 * .08 = ~10 million Firefox search queries per day [1] https://blog.wikimedia.org/2012/06/14/wikimedia-highlights-may-2012/#more-15065 [2] https://en.wikipedia.org/wiki/Usage_share_of_web_browsers#Wikimedia_.28April_2009_to_present.29 chris ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] SQL error in unit tests getting ignored
Hey, I refactored some code and then ran tests to see if it all still worked. I forgot renaming a database field somewhere, so had a query that failed. Instead of throwing an exception with the information that would have made the nature of the issue obvious, DatabaseBase::select returned false causing a type error somewhere else. This method is only supposed to return false in case SQL errors are being ignored. So why are they getting ignored? I certainly did not specify this. And it certainly is not helpful :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So what's up with video ingestion?
On 06/18/2012 04:52 PM, Brion Vibber wrote: On Mon, Jun 18, 2012 at 4:44 PM, David Gerard dger...@gmail.com wrote: On 19 June 2012 00:30, Brion Vibber br...@pobox.com wrote: warning: patent politics question may lead to offtopic bikeshedding Additionally there's the question of adding H.264 transcode *output*, which would let us serve video to mobile devices and to Safari and IE 9 without any custom codec or Java installations. As far as I know that's not a huge technical difficulty but still needs to be decided politically, either before or after an initial rollout of TMH. /warning It's entirely unclear to me that this is intrinsically related. They're intrinsically related because one depends on the other to be possible. This is a one-way dependency: H.264 output depends on TimedMediaHandler support. TimedMediaHandler in general doesn't depend on H.264 output, and should not be confused with it. -- brion I think what we should do here is go ahead and add support for ingestion and output and then we can just adjust the settings file based on what we /decide politically/ do going forward. Since both the deployment review pipeline as well as the political decision pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another. --michael ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So what's up with video ingestion?
Since both the deployment review pipeline as well as the political decision pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another. I agree with this idea. Not only does it make the political process of deciding what's best a little less painful (because it supports everything), but it also allows non-WMF projects to make the decision for themselves. By including not only the features needed by WMF projects we don't limit third parties, which although not 100% necessary, it's a nice boon. Thank you, Derric Atzrott Computer Specialist Alizee Pathology ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Facebook grabs the Mediawiki logo instead of the site logo
OK, meta property=og:image content=$wgLogo /
is what I need to add to the header of each page, as my site has no
images at all except for the logo. I use the latest git version of MediaWiki.
In OutputPage.php we see
function addMeta( $name, $val ) {
array_push( $this-mMetatags, array( $name, $val ) );
But then http://www.mediawiki.org/wiki/Manual:Hooks/BeforePageDisplay leads to
http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers
which makes one utterly totally lost. OK, then I found
http://www.mediawiki.org/wiki/Extension:OpenGraphMeta
which of course does exactly what I want... and much more.
But I don't to install any extensions. All I want is to add
that one little line
meta property=og:image content=$wgLogo /
with the $ variable (expanded
like $meta[og:image] = wfExpandUrl($wgLogo); )
or something. So how do I write the one line hook please?!
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] So what's up with video ingestion?
On 19 June 2012 21:19, Derric Atzrott datzr...@alizeepathology.com wrote: Since both the deployment review pipeline as well as the political decision pipeline can be ~quite long~ probably best to have it all supported so we can just adjust a configuration file once we decide one way or another. I agree with this idea. Not only does it make the political process of deciding what's best a little less painful (because it supports everything), but it also allows non-WMF projects to make the decision for themselves. By including not only the features needed by WMF projects we don't limit third parties, which although not 100% necessary, it's a nice boon. Hmm, yes. I concur. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Facebook grabs the Mediawiki logo instead of the site logo
I believe this should help you:
http://svn.wikimedia.org/viewvc/mediawiki/trunk/extensions/OpenGraphMeta/OpenGraphMeta.php?view=markup#l61
Personally I'd just install the extension though.. you may find you
want the other things too :)
Jon
On Tue, Jun 19, 2012 at 1:40 PM, jida...@jidanni.org wrote:
OK, meta property=og:image content=$wgLogo /
is what I need to add to the header of each page, as my site has no
images at all except for the logo. I use the latest git version of MediaWiki.
In OutputPage.php we see
function addMeta( $name, $val ) {
array_push( $this-mMetatags, array( $name, $val ) );
But then http://www.mediawiki.org/wiki/Manual:Hooks/BeforePageDisplay leads to
http://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_for_extension_developers
which makes one utterly totally lost. OK, then I found
http://www.mediawiki.org/wiki/Extension:OpenGraphMeta
which of course does exactly what I want... and much more.
But I don't to install any extensions. All I want is to add
that one little line
meta property=og:image content=$wgLogo /
with the $ variable (expanded
like $meta[og:image] = wfExpandUrl($wgLogo); )
or something. So how do I write the one line hook please?!
--
Jon Robson
http://jonrobson.me.uk
@rakugojon
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Inline styles trouble on the mobile site
So crowdsourcing fixes for inline styles doesn't seem to be the most effective method [1]. I've been quite swamped with other work just as I'm sure others have been. As a result various wiki pages are still rendering badly/unreadable. I understand that there are certain circumstances where it is useful to be able to have complete control over styling as a article writer, but I'd also argue that most article writers are not designers so what were are doing in allowing this is introducing a huge variable of complexity that allows anyone to introduce CSS that could potentially be non-performant (transitions), broken or as I am finding stuff that just doesn't work on mobile [2]. This scares me as someone who cares about providing a good experience to all our users on various devices. I ask you again... //Are inline styles on the __mobile site__ really worth the trade off?// More concretely can anyone give me a specific example of an inline style that is essential on mobile that we simply cannot scrub? I would confidently bet that if we were to turn off inline styles on the mobile site we wouldn't miss it much, and I'd much rather deal with things we do miss on a case by case basis, as at least we'd have a clean readable mobile site as a starting point. I also think people are much more motivated to fix things that they previously had and no longer have in comparison to fixing things that are currently broken. I'm sure all developers would agree that enhancements are always more fun then bugs.. :-) Can I at least get some consensus to ***try*** scrubbing inline styles on the beta of the mobile site? Note this would have no effect whatsoever on the desktop site and if we are not happy with it we just scrap it. I'm sure if we try it we might find we like it [1] http://www.mediawiki.org/w/index.php?title=Making_MediaWiki_Mobile_Friendly/List_of_portal_pages_with_problematic_two_column_layoutsaction=history [2] http://www.mediawiki.org/wiki/Making_MediaWiki_Mobile_Friendly On Fri, Jun 8, 2012 at 2:07 PM, Max Semenik maxsem.w...@gmail.com wrote: On 08.06.2012, 23:25 Derk-Jan wrote: I think we should strive to leave HTML transformation behind - for non-WAP devices we could rely on CSS only. DOM parsing made a lot of sense at the time of the Ruby gateway which had to parse HTML for screen-scraping anyway. However, now by avoiding HTML parsing we could: * Avoid performance reduction for mobile requests * Make out output more uniform * Stop relying on that unsalvageable piece of crap called libxml For specific cases when there's a lot of desktop HTML that doesn't need to be shown to mobile users at all, we could tweak the parser to ouptut mobile-specific HTML, but this should be restricted to minimum. As much as I would love to have it that way, reality in mobile apps and web apps over the past 3 years have shown me that only works for Android and iOS. Any older feature phones are, in terms of HTML parsing capability, hardly better than the old WAP phones. HTML5 and XHTML 1.0 don't mix very well in the real world. Well, we already serve either WML or HTML5, no middle ground :) -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jon Robson http://jonrobson.me.uk @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
