Re: [Wikitech-l] Search documentation
The true (old) MediaWiki documentation on search is still on Meta, it needs to be rewritten on mediawiki.org (PD and up to date): https://meta.wikimedia.org/wiki/Help:Searching Nobody reads the help pages, sure. That's why they should be linked from the special pages etc. as some extensions already do. https://bugzilla.wikimedia.org/show_bug.cgi?id=43591 Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] SMW Developer Workshop - when?
Hi Yury, some time ago you proposed a SMW webinar for developers [1], which I find is a really great idea! But it seems no date has been set yet. As there are a number of interested participants, I think we’re ready to take this one step further J and find a time slot. Shall we use the talk page? Best, Markus (mglaser) [1] http://semantic-mediawiki.org/wiki/1st_SMW_webinar_for_developers ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Jun 10, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: Created reports per component ... General/Unknown 19 ... General/Unknown 12 Isn't this strange? Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Tue, 18 Jun 2013 12:33:35 +0200, Željko Filipin zfili...@wikimedia.org wrote: On Mon, Jun 10, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: Created reports per component ... General/Unknown 19 ... General/Unknown 12 Isn't this strange? There is a General/Unknown component in several products, for example in MediaWiki and MediaWiki extensions. -- Matma Rex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Tue, Jun 18, 2013 at 12:44 PM, Bartosz Dziewoński matma@gmail.comwrote: There is a General/Unknown component in several products, for example in MediaWiki and MediaWiki extensions. Thanks, it makes sense now. In that case I think it would make sense to change the script so output is something like this: ... General/Unknown (MediaWiki) 19 ... General/Unknown (MediaWiki extensions) 12 ... Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Mon, Jun 17, 2013 at 5:00 AM, reporter repor...@kaulen.wikimedia.orgwrote: MediaWiki Bugzilla Report for June 10, 2013 - June 17, 2013 Fresh charts! http://www.mediawiki.org/wiki/Bugzilla_Weekly_Report This week UniversalLanguageSelector was added to Created reports per component chart and benapetr to Top 5 bug report closers. Željko ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Search documentation
There were over 300,000 views of [[en:Help:Searching]] in June. [1] It definitely needs some improvement, but having some accurate documentation of MediaWiki search features to work from would really help. [1] https://en.wikipedia.org/wiki/Wikipedia:Help_Project/page_statistics Peter On 18 June 2013 01:59, Federico Leva (Nemo) nemow...@gmail.com wrote: The true (old) MediaWiki documentation on search is still on Meta, it needs to be rewritten on mediawiki.org (PD and up to date): https://meta.wikimedia.org/**wiki/Help:Searchinghttps://meta.wikimedia.org/wiki/Help:Searching Nobody reads the help pages, sure. That's why they should be linked from the special pages etc. as some extensions already do. https://bugzilla.wikimedia.**org/show_bug.cgi?id=43591https://bugzilla.wikimedia.org/show_bug.cgi?id=43591 Nemo __**_ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Search documentation
My comments are based mostly on second hand knowledge. People who have tried have often ran into problems, asked for help on #mediawiki, and nobody knowing anything that can help them. Probably a large part of the issue is requiring people to install a separate (non-php) program that's not all that well documented. --bawolff On 6/17/13, Nikolas Everett never...@wikimedia.org wrote: One of our goals while building this has been to make something reasonably easy to install by folks outside of WMF. I've added some notes about this to the page. I'd certainly love to hear ways that'd make it simpler to use. Nik On Mon, Jun 17, 2013 at 8:23 PM, Brian Wolff bawo...@gmail.com wrote: Just as a note, MediaWiki default (aka crappy) search is very different from the lucene stuff used by Wikimedia. Lucene search is rather difficult to set up, so most third party wikis do not use it. --bawolff On 6/17/13, Nikolas Everett never...@wikimedia.org wrote: I'm not sure about http://www.mediawiki.org/wiki/Help:Searching but https://en.wikipedia.org/wiki/Help:Searching has lots of things we're going to have to add to our list. My guess is http://www.mediawiki.org/wiki/Help:Searching is simply out of date. Nik On Mon, Jun 17, 2013 at 4:33 PM, Chris McMahon cmcma...@wikimedia.orgwrote: On Mon, Jun 17, 2013 at 1:28 PM, S Page sp...@wikimedia.org wrote: * enwiki says Hello dolly in quotes gives different results, mw directly contradicts this. Even on my local wiki, quotes make a difference. * enwiki disagrees with itself what a dash in front of a word does. I did some research a few weeks ago on the current state of Search and there are a number of discrepancies between the documentation and actual behavior. Some of them have BZ tickets, like https://bugzilla.wikimedia.org/show_bug.cgi?id=44238 -Chris ___ 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 ___ 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] Search documentation
On Tue, Jun 18, 2013 at 11:31 AM, Brian Wolff bawo...@gmail.com wrote: My comments are based mostly on second hand knowledge. People who have tried have often ran into problems, asked for help on #mediawiki, and nobody knowing anything that can help them. Probably a large part of the issue is requiring people to install a separate (non-php) program that's not all that well documented. Well there's only so much we can do for people who are on shared hosting with only FTP and a database at their disposal. We could maybe improve SearchMysql a bit, but that's not really a goal with this project as we'd never use it on WMF sites. Solr, while still an external dependency, at least doesn't require people to build and configure a basically undocumented WMF-specific system to have a sane search. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
Hi Yuri, On Jun 14, 2013, at 7:16 PM, Yuri Astrakhan yastrak...@wikimedia.org wrote: Based on many ideas that were put forth, I would like to seek comments on this ZERO design. This HTML will be rendered for both M and ZERO subdomains if varnish detects that request is coming from a zero partner. M and ZERO will be identical except for the images - ZERO substitutes images with links to File:xxx namespace through a redirector. * All non-local links always point to a redirector. On javascript capable devices, it will load carrier configuration and replace the link with local confirmation dialog box or direct link. Without javascript, redirector will either silently 301-redirect or show confirmation HTML. Links to images on ZERO.wiki and all external links are done in similar way. For M, you only want to do this when it's a zero carrier I guess? If not, just a straight link? * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) Expected cache fragmentation for each wiki page: * per subdomain (M|ZERO) * if M - per isZeroCarrier (TRUE|FALSE). if ZERO - always TRUE. 3 variants is much better then one per carrier ID * 2 per subdomain. I'm wondering, is there any HTML difference between M isZeroCarrier == TRUE and ZERO? Links maybe? Can we make those protocol relative perhaps? We might be able to kill the cache differences for the domain completely, while still supporting both URLs externally. -- Mark Bergsma m...@wikimedia.org Lead Operations Architect Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] The summary of new zero architecture proposal
Hi Mark, On Tue, Jun 18, 2013 at 11:58 AM, Mark Bergsma m...@wikimedia.org wrote: * All non-local links always point to a redirector. On javascript capable devices, it will load carrier configuration and replace the link with local confirmation dialog box or direct link. Without javascript, redirector will either silently 301-redirect or show confirmation HTML. Links to images on ZERO.wiki and all external links are done in similar way. For M, you only want to do this when it's a zero carrier I guess? If not, just a straight link? Correct - two variants for M -- with ESI banner + redirect links, and without ESI + direct links. * The banner is an ESI link to */w/api.php?action=zerobanner=250-99* - returns HTML div blob of the banner. (Not sure if banner ID should be part of the URL) I'm wondering, is there any HTML difference between M isZeroCarrier == TRUE and ZERO? Links maybe? Can we make those protocol relative perhaps? We might be able to kill the cache differences for the domain completely, while still supporting both URLs externally. Yes - M+Carrier -- has images, ZERO -- redirect links to images ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Bugzilla Weekly Report
On Tue, 2013-06-18 at 12:57 +0200, Željko Filipin wrote: On Tue, Jun 18, 2013 at 12:44 PM, Bartosz Dziewoński matma@gmail.comwrote: There is a General/Unknown component in several products, for example in MediaWiki and MediaWiki extensions. Thanks, it makes sense now. In that case I think it would make sense to change the script so output is something like this: ... General/Unknown (MediaWiki) 19 ... General/Unknown (MediaWiki extensions) 12 ... I've filed https://bugzilla.wikimedia.org/show_bug.cgi?id=49758 , will test later this week. andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs
Max Semenick prepared a patchset that would make it possible to keep Mediawiki:Common.css and friend in sync between enwiki in production, and enwiki on betalabs, but it needs review and merge: https://gerrit.wikimedia.org/r/#/c/68309/ One of the big challenges in deploying MobileFrontend changes to production is the unexpected ways Mediawiki:Common.css and friends will affect our changes. In general, the mobile web team has been trying to get betalabs to a state that mimics production closely enough that we can reliably test our changes there for all the weird things that can happen in the production environment - before pushing our changes to production. As such, it would be enormously helpful if we had a way to keep Mediawiki:Common.css and friends in sync between enwiki in production and enwiki on betalabs. So, can someone please take a look? It would be enormously helpful for us to get this in place as soon as possible. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Announcing the Wikimedia technical search tool
On Sun, Mar 10, 2013 at 7:50 AM, Waldir Pimenta wal...@email.com wrote: Test it here: http://hexm.de/mw-search Nice. Is there a way to pass a query string to it, e.g. http://hexm.de/mw-search?q=%s ? Then we could store this as a bookmarklet with keyword 'ts'[1] and type `ts 49604` to search. It works if you do a custom search for foo and replace the q=foo in the long www.google.com/cse URL with q=%s. Nemo commented: gitblit is more robust and faster than gitweb, so it allows crawling by search engines. It's working but gitblit pages have generic title tags and no meta description or keywords, so the results don't show the title of a patch. http://support.google.com/webmasters/bin/answer.py?hl=enanswer=35624suggests how HTML pages should be structured (though Google is deliberately vague to hinder search result spammers) and https://developers.google.com/custom-search/docs/structured_data talks about rich snippets available to custom search (I've never tried it). [1] like the essential jump to Wikipedia page 'w' bookmarklet https://en.wikipedia.org/wiki/%s . Why search when you can go direct. -- =S Page software engineer on E3 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] SMW Developer Workshop - when?
A few days ago I had left a similar message on the Talk page of this. Would love to get a date nailed down if this can still happen. Jamie Thingelstad ja...@thingelstad.com mobile: 612-810-3699 find me on AIM Twitter Facebook LinkedIn On Jun 18, 2013, at 3:28 AM, Markus Glaser gla...@hallowelt.biz wrote: Hi Yury, some time ago you proposed a SMW webinar for developers [1], which I find is a really great idea! But it seems no date has been set yet. As there are a number of interested participants, I think we’re ready to take this one step further J and find a time slot. Shall we use the talk page? Best, Markus (mglaser) [1] http://semantic-mediawiki.org/wiki/1st_SMW_webinar_for_developers ___ 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] Meet Bingle and Bugello
I wrote a tool that will import bugs from Bugzilla into either Mingle and/or Trello (two project management tools used by some teams at the Wikimedia Foundation). The mobile web team was finding it difficult to keep track of two separate tools - one for new feature development, the other for tracking bugs, so Bingle helps bridge the gap and allows us to focus on one tool. This has had the side effect of keeping visibility of reported bugs high and has made it easier for us to quickly prioritize incoming bugs against existing work, and quickly respond to open issues. You can find the code and some rudimentary usage instructions here: https://github.com/awjrichards/bingle I hacked this together rather quickly - expedience was my goal rather than perfection, so it's not well documented, a little quirky, and there's a lot of room for improvement. I've been sitting on it for a while, hoping to make improvements before announcing it, but I have not found the time to make the changes I would like (eg for it to use the Bugzilla API rather than Bugzilla atom feeds). So, I invite anyone interested and willing to fork it, and pitch in and help make it awesome :) -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs
Thanks everyone who helped get that merged :) On Tue, Jun 18, 2013 at 11:02 AM, Arthur Richards aricha...@wikimedia.orgwrote: Max Semenick prepared a patchset that would make it possible to keep Mediawiki:Common.css and friend in sync between enwiki in production, and enwiki on betalabs, but it needs review and merge: https://gerrit.wikimedia.org/r/#/c/68309/ One of the big challenges in deploying MobileFrontend changes to production is the unexpected ways Mediawiki:Common.css and friends will affect our changes. In general, the mobile web team has been trying to get betalabs to a state that mimics production closely enough that we can reliably test our changes there for all the weird things that can happen in the production environment - before pushing our changes to production. As such, it would be enormously helpful if we had a way to keep Mediawiki:Common.css and friends in sync between enwiki in production and enwiki on betalabs. So, can someone please take a look? It would be enormously helpful for us to get this in place as soon as possible. -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 -- Arthur Richards Software Engineer, Mobile [[User:Awjrichards]] IRC: awjr +1-415-839-6885 x6687 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs
Le 18/06/13 20:02, Arthur Richards a écrit : Max Semenick prepared a patchset that would make it possible to keep Mediawiki:Common.css and friend in sync between enwiki in production, and enwiki on betalabs, but it needs review and merge: https://gerrit.wikimedia.org/r/#/c/68309/ One of the big challenges in deploying MobileFrontend changes to production is the unexpected ways Mediawiki:Common.css and friends will affect our changes. In general, the mobile web team has been trying to get betalabs to a state that mimics production closely enough that we can reliably test our changes there for all the weird things that can happen in the production environment - before pushing our changes to production. As such, it would be enormously helpful if we had a way to keep Mediawiki:Common.css and friends in sync between enwiki in production and enwiki on betalabs. So, can someone please take a look? It would be enormously helpful for us to get this in place as soon as possible. Hello, Thank you very much for this patch. I know it has caused various troubles to QA folks in particular. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Mediawiki:Common.css, etc from enwiki on betalabs
On 06/18/2013 06:46 PM, Antoine Musso wrote: Thank you very much for this patch. I know it has caused various troubles to QA folks in particular. Yes, this looks very helpful. I did a follow-up (https://gerrit.wikimedia.org/r/#/c/69444/1) (needs review) to add the remaining skins. It would also be nice to do all the Labs wikis (https://bugzilla.wikimedia.org/show_bug.cgi?id=49791), in addition to enwiki. Matt Flaschen ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
