Wikitech-l February 2013

wikitech-l@lists.wikimedia.org

161 participants
170 discussions

Comparisons to Confluence (was Minimalist MediaWiki? (was Re: Merge Vector extension into core))
by David Gerard 15 Feb '13

15 Feb '13

On 6 February 2013 23:58, Tim Starling <tstarling(a)wikimedia.org> wrote: > I think we can turn MediaWiki into a fully featured wiki engine which > can compete with the likes of Confluence. I don't think it can ever > compete with TiddlyWiki or UseModWiki in their respective niches. (veering slightly off topic) What in Confluence are you thinking of MediaWiki as lacking? The main two in my experience are (1) firm access control (2) WYSIWYG editor. (1) is just not something MW can promise to do securely unless pretty much every developer cared and (2) is on the way (certainly before the end of time). Any others of importance? [ps: Confluence is horrible and its hardware requirements do in fact make MediaWiki look lightweight.] - d.

24 42

Re: [Wikitech-l] [Analytics] Fwd: Page view stats we can believe in
by Lars Aronsson 14 Feb '13

14 Feb '13

Hi Erik, > You're quite right numbers are inflated, and we've been over this before [1]. > Below are some sampled data for da.wiktionary from webstatscollector [2] and squid log [3] > Bot traffic is a substantial share of 'page views' (but not the majority as you suggest). > > We discussed this extensively in April and as I remember (my mail archive is somehow incomplete) > decided to implement a second cleaned-up stream > without /bot/crawler/spider/http (keeping the original stream so as not break trend lines) > > However that bot free stream (projectcounts files with extra set of per wiki totals) > never happened yet, and I'm pretty sure we changed plans since, > and probably now wait for Kraken. Diederik can you add to this? Oh my, I thought this was in operation already. I've actually been looking at these page view stats, and now I feel like a fool. Why not just remove these web pages at http://stats.wikimedia.org/wiktionary/EN/TablesPageViewsMonthly.htm since they contain only nonsense? Continuity with old nonsense is still nonsense, so remove everything now and start a new project with real numbers. > [1] On April 8, 2012 you reported a similar issue for Swedish Wikipedia. > I checked by then one hour of sampled squid log. 9 out of 13 requests were bots. Nobody doubts that the Swedish Wikipedia has a substantial amount of human traffic. But for smaller projects, the background noise will dominate. If bots are 9 out of 13 requests to sv.wikipedia (really?), they can easily be 99% of traffic to da.wiktionary. One easy way to tell would be to observe the daily rhythm. Since Swedish and Danish are limited to one timezone, traffic in the middle of the night should be much smaller than mid-day traffic. But bots could be operating all night, all day. So the least active hour is probably the background noise from bots. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

5 6

Maria DB
by Petr Bena 14 Feb '13

14 Feb '13

Hi, I have installed Maria DB to all my servers, including production servers few weeks ago, and I found it quite stable and I like it (even the command line tool for working with sql is far better than the one included in mysql pack) It's supported on all latest ubuntu versions from 10.04 UP (maybe even older) - so my question is, are we going to use it on wikimedia production? I think we could migrate beta cluster for now - it has terrible performance and this could help. It could be a first step to migrate wikimedia production cluster.

11 16

Stable PHP API for MediaWiki ?
by Mariya Nedelcheva Miteva 14 Feb '13

14 Feb '13

Hi all, I have been talking to many third-party yas part of my WMF internship in the last few weeks and one the main concerns they express is the lack of stability in the PHP classes MediaWiki exposes from version to version. The frequent changes in what I would call the PHP-API makes extentions developement and maintenance much more difficult with compatibility from version to version becoming a problem. Solving the problem would probably result in the development of more extensions, easier maintenance, less hacks to core and more users upgrading to the latest MediaWiki version. I am sure WMF developers are facing similar issues especially with projects like WikiData going on. My question is: With the given technical heritage that MediaWiki carries, is it possible to have a (relatively) stable set of PHP classes defined, with a pledge not to change them in the next X releases or at least with some longer deprecation time? What would maintaining such a PHP-API entail? How difficult is it given the vast number of dependancies in MediaWiki code? Does it require restructuring a lot of the current core code? Do you think it should be a definite goal for WMF? Thank you. Mariya

16 27

Font at dv.wikipedia and dv.wiktionary
by oәuɐႡɔsʇnәp nɐႡsn 14 Feb '13

14 Feb '13

Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If possible could the fonts be changed to Faruma which can be downloaded from here: http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf… . Originally this issue was raised at http://dv.wikipedia.org/wiki/User_talk:Glacious#Fonts by User:Vituzzu. I have tried http://www.mediawiki.org/wiki/Extension:WebFonts#Preparing_webfonts but to no result. Can someone help me regarding this matter. Links: dv.wikipedia.orgdv.wiktionary.org MediaWiki - 1.21wmf8 (17a7840)PHP - 5.3.10-1ubuntu3.4+wmf1 (apache2handler)MySQL - 5.1.53-wm-log I have posted this question at the MediaWiki support desk here: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Font_at_dv.wikipe… and User:MarkAHershberger directed me to https://bugzilla.wikimedia.org/show_bug.cgi?id=42812 but no one is responding in there. So he told me to mail to this list. Regards,Ushau

9 19

ResourceLoader sanity check
by Nikola Smolenski 14 Feb '13

14 Feb '13

At http://www.mediawiki.org/w/index.php?title=ResourceLoader/Features&oldid=64… it is written: It starts by performing a quick sanity check that bails out if the current browser is not supported. This saves bandwidth as well as preventing broken interfaces, basically leaving the user with an untouched page with the natural non-javascript fallback behavior. Browsers such as Internet Explorer 5 and early versions of Mozilla fall in this category. While I see that it works, I can't find where exactly in the code is this sanity check located. Any pointers?

2 1

Fwd: Re: How to speed up the review in gerrit?
by vitalif＠yourcmc.ru 14 Feb '13

14 Feb '13

Sorry, I've replied to Sumana directly instead of the mailing list. So now duplicating into the mailing list. Sumana Harihareswara писал 2012-12-19 22:30: > Try these tips: > https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews Sumana, it's all very good but: 1) I think it's not so comfortable to push other developers personally when adding them as the reviewers... And I don't know whom to add as the reviewer, so I just choose randomly. But what if that guy doesn't want to do review for that extension? For example what if he is already very busy in working on mediawiki _core_, and I ask him to review a trivial extension? 2) Who can verify changes in extensions? There is no CI. So, people who can verify changes and people who can put +2 - are they the same people? But it again leads to short-circuiting all the work to the "core" people, and aren't they already busy? (I assume they are as they don't review all the changes) 3) As a solution, I think it would be good if - at least in not-so-important-as-the-core extensions - the changes merged automatically after getting, for example, 2x "+1"... Or will you end up with changes reviewed by not merged by anyone? And also, maybe it would also be good if the system automatically added some reviewers - randomly or based on some "ownership" rules...

11 21

Can we kill DBO_TRX? It seems evil!
by Daniel Kinzler 14 Feb '13

14 Feb '13

Hi all! Since https://gerrit.wikimedia.org/r/#/c/21584/ got merged, people have been complaining that they get tons of warnings. A great number of them seem to be caused by the fact the MediaWiki will, if the DBO_TRX flag is set, automatically start a transaction on the first call to Database::query(). See e.g. https://bugzilla.wikimedia.org/show_bug.cgi?id=40378 The DBO_TRX flag appears to be set by default in sapi (mod_php) mode. According to the (very limited) documentation, it's intended to wrap the entire web request in a single database transaction. However, since we do not have support for nested transactions, this doesn't work: the "wrapping" transaction gets implicitely comitted when begin() is called to start a "proper" transaction, which is often the case when saving new revisions, etc. So, DBO_TRX sems to be misguided, or at least broken, to me. Can someone please explain why it was introduced? It seems the current situation is this: * every view-only request is wrapped in a transaction, for not good reason i can see. * any write operation that uses an explicit transaction, like page editing, watching pages, etc, will break the wrapping transaction (and cause a warning in the process). As far as I understand, this really defies the purpose of the automatic wrapping transaction. So, how do we solve this? We could: * suppress warnings if the DBO_TRX flag is set. That would prevent the logs from being swamped by transaction warnings, but it would not fix the current broken (?!) behavior. * get rid of DBO_TRX (or at least not use it per default). This seems to be the Right Thing to me, but I suppose there is some point to the automatic transactions that I am missing. * Implement support for nested transactions, either using a counter (this would at least make DBO_TRX work as I guess it was intended) or using safepoints (that would give us support for actual nested transactions). That would be the Real Solution, IMHO. So, can someone shed light on what DBO_TRX is intended to do, and how it is supposed to work? -- daniel

9 19

Making the "query" & "opensearch" API working fine on a self hosted wikimedia server
by Hicham TAHIRI 14 Feb '13

14 Feb '13

> Hi all, > > I'm Hicham from Paris. I just created a young company which mission is to > "make the web speak" :) > As a first step, I'm building a french version of "*Wofram Alpha Q&A like" > * system based on dbpedia & wikimedia API. > > As I had some issues to get quick API results for queries, I decided to > install wikimedia and host my own version of the french Wikipedia. > I did the install from scratch. > Following the online documentation, I managed to do it using MWdumper > http://izipedia.com/mediawiki/index.php?title=Wikip%C3%A9dia:Accueil_princi… > > *My first issue is the following:* > I have an article in wikipédia about this guy: > http://izipedia.com/mediawiki/index.php?title=Andr%C3%A9_Manoukian > When I search for it in the french official wikipedia api server I got a > result > > http://fr.wikipedia.org/w/api.php?action=opensearch&limit=10&format=xml&sea… > but not in my server > > http://izipedia.com/mediawiki/api.php?action=opensearch&limit=10&format=xml… > > Although, in other cases opensearch works fine > > http://izipedia.com/mediawiki/api.php?action=opensearch&limit=10&format=xml… > > Any idea ? > > *My second issue is the following:* > Api calls never work with the param "*query*" > See for example > > http://www.izipedia.com/mediawiki/api.php?action=query&list=search&format=x… > wich once again is working really nicely in the official server > > http://fr.wikipedia.org/w/api.php?action=query&list=search&format=xml&srsea… > > In advance thank you very much for your kind advices, > best regards, > Hicham > > -- > > *Hicham Tahiri | Founder of Vocal Apps* > *+33760747891 | www.vocal-apps.com | @vocal_apps<http://www.twitter.com/vocal_apps> > * > *24 rue de l'Est, Paris Incubateurs 75020 Paris* > > >

5 6

'Page View' Stats for the Timed Media Handler
by Matthew Walker 14 Feb '13

14 Feb '13

Greetings all, Victor is releasing a video tomorrow for valentines day and whilst I was discussing it with him, the topic of "how many users actually watch our videos" came up. Do we currently have a way of collecting play/click stats for content played by the TimedMediaHandler off of commons? If not, does anyone have any ideas on how to go about getting this information? ~Matt Walker Wikimedia Foundation Fundraising Technology Team

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l February 2013