#MediaWiki - #MediaViewer rehashed

Some things are plain stupid, sometimes I am and sometimes someone else is. I filed a bug about my experience of the MediaViewer. For me it is a show stopper; it prevents me from using it easily.

The problem is that Chrome shows a really awful URL for an image with funny characters in its title. When I look at it using the MediaViewer it is bad but it looks fine when I look at it from the Commons page.

• File:%C3%89cole_normale_sup%C3%A9rieure_de_Paris,_26_January_2013.jpg
• File:École normale supérieure de Paris, 26 January 2013.jpg

According to the Bugzilla triage I must be stupid because it works; it complies with specifications and, indeed technically it works. It just stopped working for me.

Several reactions are possible. My choice was to shrug, mutter "it is the user experience stupid" and I got on with my life. Others find it a precursor to the invasion of an evil overlord who does not understand the world and prepare for war.

By filing a bug, by posting this blog I have rid myself of my frustrations. I know several developers; I met many of them at Wikimania and I know they are really dedicated and mean well. I also know that such things pass. I am sure someone will see the light or Google will fix Chrome (if that is where the bug lives). In the end I do not look at images that often as a result.
Thanks,
       GerardM

#Mediawiki - the #Media viewer

The #Wikimedia Foundation has a problem with people accepting new functionality. The reasons why are often irrational and steeped in conservatism but that is another story. A blog post does not help much at that.

What may help is the assessment of bugs. In bug 68372 it has been identified that in certain browsers a name like MilutinDostanić.jpg will show up properly in the URL when seen from Commons and not from within the Mediaviewer. The Mediaviewer will show it like MilutinDostani%C4%87.jpg.

Technically, technically there is nothing wrong with that. From a user perspective it looks like shit. When a bug is closed because technically there is nothing wrong and a difference in behaviour is not considered as being of enough relevance, a user gets pissed off.

When bugs are reported and when user acceptance is important, differences between expected behaviour and actual behaviour become important because they are often what prevents acceptance of new functionality.
Thanks,
     GerardM

#RTL support in #Wikimedia #Commons

The screenshot below shows splendidly how #MediaWiki has improved its support for languages like Arabic and Hebrew. The sidebar is to the right, the labels used for the image are in Arabic and the descriptions are in the direction of the language indicated.

As you can see, the "Summary" is a text in English and it is displayed in the wrong direction for English. This is probably the consequence of the software not knowing that this text is in English.

This is clearly a bug and it needs to be reported. The obvious way is to report this in Bugzilla. A bug reported in Bugzilla ensures that there is a record of this issue. It is likely that more issues like this bug exist where support for the use of RTL languages breaks.

In the Localisation team we are exploring the known RTL bugs. This is the best time to experiment with the combination or RTL languages and LTR languages because at this time we are extremely receptive and are able to resolve them relatively quickly.
Thanks,
       GerardM

#MediaWiki 1.18; RTL is no longer like Mr Bean driving in France

Support for right to left scripts is one of those un-holy grails that everybody seems to be looking for. The objective is for readers and editors to easily read and write.

When it is wrong, it feels like driving in Great Britain where nobody will drive on the right side of the road. Everything is where you do not expect it and, it looks awkward.

With release 1.18 MediaWiki many bugs that have to do with mixing and matching scripts with different directions have been tackled. On Commons and any other wiki, the sidebar will be on the side where it makes sense for the language of your preference. For languages like Urdu, Persian, Arabic and Hebrew, it will be on the right side. The content itself, in the text box will show as it should for the "content" language.

The Localisation team has been tasked to crush the rest of the RTL bugs. Guess, what we KNOW about the bugs is in bugzilla, so when there are more bugs for us to crush, this is the time to identify them to us .... and bugzilla is where we are looking for them.
Thanks,
      GerardM

Responding quickly gets you a quick turn around time

Bug 31310 was reported the other day by "Barry". His #Wikipedia experience was broken. He posted a very complete bug report, he was asked a question and he replied instantly. This kept everyone in the flow.

As information came in fast, MediaWiki was fixed fast. The Samsung SCH-U430 works fine in test and the fix will be rolled out in the next release window.

Bugging us properly works. Try it when you need to.
Thanks,
       GerardM

An issue with #MediaWiki is a nice pain

When #Wikipedia breaks, you are upset. You want to yell and get attention for what breaks.. Take for instance this one; you can skip the next paragraph, it is about a mobile that no longer works.

I am using a Samsung SCH-U430 cell phone to access the moblle version of Wikipedia. The URL that I have always used is http://mobile.wikipedia.org. All of a sudden the link won't work today, I get the error message "Parser Error". My phone is using Obigo Browser Q04C1-1.22 built on Apr 27 2010. I have tried other URL's such as m.wikipedia.org, en.mobile.wikipedia.org, and en.m.wikipedia.org. They still give me the same parser error. I also notice that that mobile Wikipedia site is a beta version. Can anybody help me out to get mobile Wikipedia working again on my phone? All my other bookmarks and other websites that I go to work as before. — Preceding unsigned comment added by 70.81.58.142 (talk) 16:34, 2 October 2011 (UTC)

What anonymous may learn is that a friendly developer explained the cause on the village pump. What anonymous will not know is that that the same developer signalled it to the right people on IRC and really that is all I can see.

The best way to report a problem is by entering a bug in bugzilla. This is another way an open source project shines. You enter a bug, and you are kept informed about how that bug progresses and may signal the existence of the looked for solution at the end.

"Barry" may be our anonymous user but Barry entered a bug; bug 31310 with the same description. For him it is a blocker and I am sure that someone will give it the rating that applies within the MediaWiki mobile development. Barry and I will be informed about future developments. Even when nothing gets done, we will know.

Compare this with commercial products, bug reports go into a black hole and you never learn if and when there will be a solution.
Thanks,
       GerardM

Q&A with the #MediaWiki #bugmeister

As more developers are working on the MediaWiki software, keeping a grip on the outstanding issues becomes more then a day job. Mark Hershberger has as its task to manage the needs of the community and does this in a hands-on fashion by bringing focus to the bugs reported in Bugzilla.

He has been doing it for a while now and this interview may give you an idea why having a bugmeister is a great idea.
Enjoy,
      GerardM

Can you explain what a bugmeister does
The main idea of a bugmeister, is clear from the posted job opening. This basically says that the bugmeister acts to bring the community's issues to the attention of WMF Project Managers and Developers. In addition to making sure the community's needs are heard, I've also worked recently to get the developers from the community involved in WMF activities. For example, I'll be hosting a fund-raising-focused triage in a few weeks where community input is wanted.

There seems to be more work then can be done by one bugmeister, is it true that by focusing on what needs the most tender love and care, you pick from the low hanging fruit ?
There are a lot of bugs in Bugzilla (over 6000 open issues right now) so I admit that bug-solving is driven somewhat by the squeaky wheel since those are the issues the community has shown the most interest in.  I do want to chew through those other bugs but I think that focusing on the new bugs and most-often referenced old bugs will get a lot of these bugs handled.

WMF is very much into agile development, is a bug triage something that you do at the beginning or at the end of a sprint

Good question.  I'm not sure I have an answer, but let me try.

Part of the purpose of triage -- at least how we're using it at the WMF -- is to understand problem reports and how to solve them and, after that, to assign them to a team or a person to work on.

So, as far as I understand sprints, triage would happen at the beginning.

Identifying and assessing the new bugs is what I understand you do. How does this fit into the process of fixing bugs
This varies with how high a priority the bug gets. For a quick overview of the time-line of my involvement time-line see the documentation on MediaWiki.org.

For example, bugs that are "highest" priority get very close attention. "high" priority bugs less so, and so on.

Every week there are more new bugs then there are bugs that are marked as fixed, how significant is this?

First, the weekly bug report isn't completely accurate -- it has some bugs.  For example, I noticed recently that it had reported 594 bugs created in one week when a query shows only 122 were created that week.

Second, it is normal for projects with open bug reporting tools to have more bugs created in a given period than closed.  I'm having trouble finding the report at the moment, but I recall seeing Mozilla Firefox had more bugs opened in a year then closed.

There is a perceived lack of people working on the review of software, can you comment
Over the past year Rob Lanphier has worked to get more people reviewing the code since, yes, we had too few people doing code review. We're in a lot better position now, but we still do not have the resources to review every bit of code that is in subversion.  I'd rather make the code repository and code distribution available to anyone who wants to extend MediaWiki, since this is better than telling people "We can't review your code, so it isn't welcome!"

As an example of how code review has gotten better, Rob Lanphier and I have been doing a lot of work on getting code reviewed faster and code marked FIXME fixed faster as we ramp up to a 1.18 deployment. This is a big pain point since we want to make more frequent releases of MediaWiki and become, as you pointed out, more agile.  And we don't want to release un-reviewed code.

I think, though, that if you look at the way FIXMEs have been resolved, or how new revisions have been reviewed, that you'll see some very good trends. In the past few weeks we've really been driving unreviewed code down pretty hard.  I'm confident that we can continue to keep unreviewed code low.

Code not written by WMF employees is certainly reviewed -- especially if it is going to be deployed on the site or released as part of MediaWiki. Since we only have limited resources, we cannot review all code in our Subversion repository.

For example, we host Semantic MediaWiki and extensions, but this code is not used on any Wikimedia website and is not distributed as part of MediaWiki, so, in order to make sure that the code we do release reviewed, we have to ignore Semantic MediaWiki for the most part.

An example of MediaWiki code that is not used on the cluster, but that is reviewed is the new Installer for MediaWiki or code that supports databases other than MySQL (such as PostgreSQL).  But, when it comes to Database code we're somewhat limited in our ability since we're so focused on MySQL, so we are looking to recruit volunteer reviewers who use and are familiar with the other databases that MediaWiki can use to help review this code.

Siebrand indicated that the presence of people from many disciplines was why the recent i18n bug triage was so successful. How does this mix with the small teams typical of agile?

Triages are more successful when more people are involved, true. Since a basic part of the Bug Triage, at least in the way I've been running them, is open community involvement -- I hold the triages on IRC and everyone is invited -- I don't think we're limited by small teams.

What is the measure of your success; is it in the volume of work done on bugs or is it in a changed way or working of the developing community or is it a mix of things

I think it is still too early to answer that question definitively. I'm actually working with a researcher to find out what sort of metrics we can find in the bug database to draw good conclusions about community involvement, # of bugs solved, and the like.

A function like a bugmeister seems far removed from the community editing on the projects, do you and how do you keep informed on what happens in the projects

I work with different community members to enable editing on the projects. Extending the functionality of a project like we did with the Google News Site Maps (GNSM) extension on wikinews is a big part of that.

This coming Wednesday, I am having a WikiBooks-focused triage with some people from that community that I met in the Collection extension triage. During this time we'll be able to find out how we can help their project succeed more.

What is your favourite MediaWiki project, what is the most challenging project
I admit a soft spot for WikiSource, but this is mostly because I think we could use it to provide a community-driven replacement for ReCaptcha. Google is using ReCaptcha to help the New York Times scan in old newspapers, but, as far as I can tell, they aren't making the result publicly available. I think we can do better.

Thanks,
Mark.

What to do to fix #MediaWiki #language bugs

When we know what issues need to be addressed, we analyse them, we categorise them and then we ask who wants to fix them. It sounds simple and actually, it is a great way to get more people involved.

A bug triage has been held for the second time and this time two new people demonstrated their interest in working on language issues.

The process is quite cool; Siebrand really explained the issues in a bug, he indicated what skill level is needed and, what benefits there are to solving a bug. Bug 16175 for instance has to do with the EditPage.php class, something Roan qualified as nasty and Bawolff as something that scares him late at night.. Fixing it may result in a need for many new messages that need urgent localisation. The upside is that it is a great introduction to some of the hard parts of the MediaWiki code.

Not everything was hard; some people indicated that they wanted to get involved without working on code. For them there were changes to the language of messages, the documentation of messages. The bug triage truly provided quite diverse opportunities.

As the people participating was quite diverse, the hour reserved for the triage ended with a discussion on a schema change. This high level discussion was nice because of the pragmatic way the consequences were discussed. A log of this triage has been published. Read it, it may whet your appetite to get involved in MediaWiki and language support.
Thanks,
        GerardM

#Hindi #Wikipedia has 100K or 10.00.00 or one lakh articles

News on the mailing lists has it that the Hindi Wikipedia has one lakh articles. A lakh is 10⁵ and it is one of those numbers we happily recognise as a cause for celebration. So, congratulations to the Hindi community and lets hope that this auspicious occasion will translate in a project that will be increasingly popular.

A lakh is a unit in the Indian numbering system. These numbers are written differently from what most of us are used to. It just happens to be the same as 100.000. Numbering systems are defined in standards and, the appropriate standard is the CLDR.

Given that we do support languages and consequently peculiarities like different numbering systems, there is a Bugzilla bug asking for the support of the Indian numbering system. It has been scheduled for proper attention and, that is a sign of the Wikimedia Foundation doing good for all the cultures it supports with its projects.
Thanks,
       GerardM

Get ready for next gen #Wikipedia #Mobile

It is easy to check if your #Wikipedia is ready for the next generation mobile support. What is extremely good information is that the first iteration will be the replacement of the Ruby engine with a PHP engine.

The consequence is that initially, the user interface will not change. This means that you can check here at translatewiki.net if your language has its user interface completely localised.

When all the messages are translated, you need to request for the localisations to be brought into production. This is done by adding a bug to bugzilla. This is needed for the current Ruby interface.

Another step that you can take is the creation of a mobile main page for your language. Without a mobile main page and the localisation it will look like this example for the Pontic language.

With a mobile main page, sections of the main page will be provided by clicking on a button like in this example for the Indonesian language. This is particularly friendly on those people for whom the use of bandwidth comes at a premium.

Apparently bandwidth in the Netherlands is not considered much of an issue; its mobile main page shows more of the main page.

Given that the mobile use of Wikipedia is where most of its growth in traffic is, it is also growth where your language may benefit. When the result is less then successful, it is good to remember to post a bug in bugzilla because once the next generation PHP mobile engine kicks in, it will get attention.
Thanks,
        GerardM