#Wikidata - Mrs Helen M. Duncan is not the only geologist

There are many ways of updating Wikidata. Individual statements for individual items are made. They are worthwhile but on the grand scale of things they have little impact. Another approach is to seek sets of data that can be updated all at the same time.

Mrs Duncan is among others relevant to the Smithsonian Institute. The approach of adding loads of data for many people has the advantage that when the same issue like Mrs Duncan not being identified as a geologist, is fixed for many people at the same time.

To do this, I identified a category that implied the missing statement and I used PetScan to add all of the missing data in one go. Together with Mrs Duncan I made 1005 humans a geologist.

These are small numbers, they hardly register. But as it is, there are Wikidata administrators actively preventing edits because Wikipedia cannot cope with the volume of changes in its recent changes. 

There is no plan, no timetable for the underlying problem to be solved. Wikidata people are told not to make mass edits. It is however the only way to make a real difference and make Wikidata halfway usable.

There are two options:

• improving Wikidata as fast as we can and in the best way possible - as a consequence changes at Wikidata will not all be visible in some Wikipedias
• allow Wikidata to edit to the extend that Wikipedias can keep up with the volume of changes - as a consequence people will go away and new projects will not start

There is a prima facie case to be made for the edits to be seen in the Wikipedias. Its efficacy has not been studied and some say that the user interface sucks too much to be useful. Arguably keeping these changes is based on beliefs/assumptions and not on established facts. 

We should imho make all the edits we can make and when the Wikipedia recent changes are to be salvaged, give it the highest priority particularly at the Wikipedia end. It sucks that we can not provide all changes to them but hey that's life. 

Thanks,

      GerardM

#Wikidata - a bug busted

Automated descriptions is the single most important productivity enhancement for Wikidata. Nothing else comes close. Most items do not have descriptions and many of these fixed descriptions do not exist in my language. Automated descriptions are not fixed and improve as more relevant statements become available.

I was getting depressed when they became absent after an update of Wikidata. How would I know what "Jodhpur" to choose when I want the Lok Sabha electoral district? I found how much I rely on this feature and how crappy Wikidata is without it.

Magnus came to the rescue and I have updated my "common.js".  It now says:

mw.loader.load('https://en.wikipedia.org/w/index.php?title=MediaWiki:Wdsearch-autodesc.js&action=raw&ctype=text/javascript');

It works again for me. It can work for you as well and it will work for all of us when this functionality is available to all of us.

Please make it so!
Thanks,
      GerardM

#MediaWiki Talk pages

#Wikidata uses talk pages. The #Wikimedia Foundation is working on a tool called "Flow". As is usual, there are those people who want to keep everything the same. They love their system.

It is fine and dandy. When I added a comment on the Wikidata "Chat" I could not click on the appropriate edit button and get the right section. As it is ,Talk is flaky as well and it is not as easy and obvious as it is made out to be.
Thanks,
     GerardM

#Reasonator - Tancred, Prince of Galilee

This fine man from Normandy, has an extended family. When you look at his "family tree", the software stops when it says: "11464 people loaded, 9 queries to go". 

What amazes me is the sheer amount of effort that has gone in adding all these relations. As far as I am aware, this is all done by hand. Tancred is not the only example with too many relatives to show.

When you look at the inline information in the Reasonator, you use the same functionality that can also be shown externally. When Magnus is to look at this bug, there are a few considerations:

• he has to know about the bug
• he has to have the time to fix the bug
• it has to fit in his priorities

Magnus has a huge capacity to do all kinds of everything, he has a day job. Given all that, he does not scale :)
Thanks,
     GerardM

#Reasonator - bugs and a different kind of awesome

Unlike Pallas Athena, Reasonator did not rise fully armed out of the head of Zeus. It has developed incrementally and every now and then it has its moments where bug manifest itself. It is software and, Magnus does a splendid job at terminating bugs.

The typical workflow is as follows:

• build a feature
• test in test
• promote to live environment
• bug Magnus with a bug (reiterate process)

This works well enough. Typically the environment Reasonator operates in is stable and bugs are obvious. Sometimes there are issues. Issues like a major re-write of functionality and an upgrade of the Labs environment. This is when the unexpected happens and bugs have an impact on functionality.

At this moment the update process kills Reasonator. But as the show must go on, it is better to do away with updates for some time until there is a bug fix. At this moment the daily backups are not available in the new Labs environment. The problems with updates cannot be limited to only one day.. BUMMER

The good news is that one bug has been found and fixed. It was late so it was time to sleep. Today it will be time to test. When things turn out to be fine, the update process will run again and both Reasonator and WDQ will provide near real time results from Wikidata.

It is when all the small things that happen every day that amount to so much start to show up again.

Thanks,

      GerardM

#Wikidata - About #lists, page views and #language support

I positively hate lists. They should have only two statements one should indicate that it is a list and the other should indicate what the list is about. The problem is that many Wikipedias think a list is a substitute for the real thing.

When you look at the statistics for the Reasonator, you will find that there is no interest to see the information it provides in Arabic. So far there have been only 24 page views ... How to double this and double it again, how to find an audience for information presented in Arabic.

One way is to have information that they might like, this is why I did some work on the kings of Saudi Arabia. However, it then shows that the timeline screws up in that the buttons for right and left overlap. It is open source and a solution is welcome.
Thanks,
      GerardM

What #priority? Applying #standards

Bug 8217 is old. It is about applying standards to the naming of Wikimedia project. The bug was filed in 2006 and as time goes on, an increasing number of people are upset. Some have gone to the next stage and became bitter.

One upset Wikimedian changed the priority of the bug to "immediate" and, given the law of the land, it was changed back to "normal" by an administrator.

At this time, several Wikimedia languages are not properly identified. Applicable standards should be applied. A really long time ago the language committee was created to prevent future issues. We are still waiting for the old pain, the old wrongs to be righted.

Please Wikimedia powers that be, please intervene. Please make sure that these issues are resolved.
Thanks,
      GerardM

#Wikimedia #HOWTO - Supporting dyslexic people

One small detail that deserves much more attention is the ability to support people who are dyslectic. This support is thanks to a wonderful little project called OpenDyslexic. It is a font that is designed in such a way that most persons with dyslexia find it a lot easier to read.

There are several reasons why our support for dyslectic people deserves more attention;

• seven percent of a population is dyslectic
• people who have found how to enable this font are happy
• we do not know how many people use OpenDyslexic
• we are told that people find it hard to enable the font
• OpenDyslexic could be used for languages like Polish
• some languages cannot use OpenDyslexic because characters are not supported

The CEE conference in Modra was really constructive; so many subjects were discussed including OpenDyslexic. The bug to enable OpenDyslexic for Polish, indicates that many of the things discussed are actionable and are being acted upon.
Thanks,
        GerardM

Reviving my bot for #Wikidata IV

An appropriate response of a fixed bug is .. more testing. The harvest_template.py did get a bug fixed so testing the latest and greatest was in order. The bug has been fixed. I am grateful so it was time to do run attempt to import more data from Wikipedia and do some more testing at the same time.

At this time I am importing political party information from templates of obvious politicians; people who are for instance in a category like "Presidents of Argentina". I found new bugs..

• When there is no party indicated, the bot aborts
• When the party is a "red link", the bot aborts
• When there are multiple parties indicated, it only adds the first one

I also found that there are Wikipedia articles without a Wikidata entry, they are ignored. 

I am really happy with the help I get in running the pywikipedia software. It becomes however obvious that importing data from Wikipedia into Wikidata in this way is not mature.

Thanks,

       GerardM

PS I imported some 400+ records while testing :)

"I do not know the language" in more languages

When you have a user of every #Wikipedia, it is fairly obvious that on most Wikipedias you do not know anything of that language. When I provided this information on the Wikipedia in Haitian, the message came out in French.

This was wrong on many levels particularly because the localisation of the Babel extension in Haitian is hardly recent. It pre-dates the current release of MediaWiki.

The good news is that this bug has been fixed. We know that it affected the Babel extension but it would not surprise us when it affects other extensions as well.

When you find all of a sudden many more localisations available for your language, you can assume that it is because bug 33768 has been fixed by Roan.
Thanks,
       GerardM

The #agile #bugmeister

The #Wikimedia bugmeister works in an environment where increasingly more development teams adopt agile for their project management. As the function of a bugmeister is not defined in agile, the question was raised during the training for the localisation team what a bugmeister is in an agile environment.

We love our bugmeister and, we want to fit him in. The short answer is that a bugmeister represents aspects of both business analysis and quality control. The long answer has it that software is accepted based on the compliance of a "user story" in the software. For a reported bug to be a bug in the understanding of agile, it does not comply and it results in a user story explaining the breakage. The existence of a bug may also indicate that a "user story" exists where the existing functionality does break. The analysis of such a situation is what a business analyst does. The resulting user stories are presented to the "product owner" for inclusion in a next sprint.

When the previous paragraph sounds like gobbledygook, it is very much because of the specific terminology used by agile. Having specific terminology is a good thing because it forces an agile newbie to consider and reconsider his understanding of what is expected of him or her.
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

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

#mwhack11; templates do not scale for #Wikipedia

The #WebFonts extension does one thing well; it provides web fonts when they are available for the language selected in the user preferences.

That is great for an initial roll-out because it provides a service to people for whom a wiki is intended. Amir argues rightfully that there is a need for web fonts when a text is written in a language where we know that fonts are likely to be lacking.

In some Wikipedias there are templates that identify a text as being in a language different from the language standard for that wiki. Such a template can be extended with an optional web font. It will work when the extension makes the web fonts available.

The problem is that there will be a need for one template per language and such a template will be needed in every Wikipedia. While Amir can do this for a Hebrew wiki, he cannot do it for all wikis; it is just too much work.

It makes more sense to include the ability of identifying a language and selecting a web font in an extension. This could be WebFonts v2.0 and, there is already a request for it.

Thanks,
      GerardM

#MediaWiki has <ref>; but look at it in #Hebrew

The #mwhack11 is an important meeting to squash bugs. As the Language committee has its meeting and as there is a large group of translatewiki.net developers, there was a dedicated session on "right to left" issues.

Some five bugs were squashed. They were the known bugs, the bugs that were documented. There were bugs that had so far not been given the attention they deserve; one bug kills the wish to actually use references in a Wikipedia article.

When you do <ref> some source </ref> you will get another entry in this nice reference section at the end of the article.

You can find the complete <ref> tag in the screen shot. For your convenience, it has been highlighted in blue. From a usability point of view, it is atrocious. It is so bad that even Mr Michael Everson himself was shocked.

Now there is a bug for this issue and there is a chance that the Hebrew community will overcome their reluctance to include sources in their articles. One lesson learned is; there is a relation between localised technology and the quality of a Wikipedia.
Thanks,
        GerardM

Can we have functional #fonts for #SVG please

At the Malayalam #Wikipedia they have a project where they work on maps. It is a hug effort and we cannot share their hard work. Bug 24000 and bug 25140 indicate that pango and rsvg need to be updated.

After these bugs were filed SVGtranslate was internationalised in many languages including Malayalam. It will likely be localised in all the Indian languages we have Wikipedias in. These maps are relevant to all these Wikipedias. It may even stimulate more people to create maps of districts in other Indian states.

This bug is a show stopper. It may be that once these applications are updated, we need to support more fonts in our SVG engine. Many fonts have been selected already for the WebFonts extension...
Thanks,
      GerardM

PS it is not only Indian languages that will benefit

What to do when the #CLDR does not have it II

In #MediaWiki messages we support the plural of items. Its implementation differs per language and at translatewiki.net we use the CLDR as the source for these rules.

This presents its own problem as the CLDR does not do fractions. Saper has just added Bug 28128 - "Consider whether {{PLURAL:}} should handle fractional numbers".

Having proper support for fractions is relevant when you want to inform for instance how many millions the Fundraiser has made for us. The current messages are mostly based on lists so that keeps it nicely integer.

Given the complexity of the support for integers in all our languages, it is a nice can of worms we are opening up. It helps that the Fundraiser only starts in November.
Thanks,
        GerardM

Our #bugmeister makes me happy

Bug 6100 - "Allow different directionality (rtl/ltr) for user interface and wiki content" is an old one. It goes back all the way to 2006. Many people commented over time and several issues mentioned have already been overcome.

By raising the priority of this bug to "highest" and "major", a clear signal is given by the Wikimedia Foundation that support for languages like Arabic, Farsi, Hebrew is important. Actions like this and the recent work on the implementation of Narayam demonstrate this support visibly.

Support was announced in words but these actions speak for themselves and empower the words with reality.
Thanks,
     GerardM

Our #bugmeister gets you hooked

A homonym

What our #MediaWiki bugmeister does can be compared to the processes you find in healthcare. The patient says what ails him; for instance we want to get MediaWiki 1.17 stable and released. The first thing he does is triage, what bugs us. What prevents the release.

Then the magic starts to happen; communication.

An e-mail to the Wikitech-l with an invitation to a weekend sprint to swat those pesky bugs. This invite is to any and all MediaWiki hackers and it gives them focus and rapid review and implementation. Exactly what you do when you want people to be involved.

For those developers who do not know what to do in the rest of the week, there have been suggestions to work on the "Highest priority bugs" or on the "Most Popular bugs". These invites attract attention not only are people now working on these bugs, they are also changed when they need to get the attention of the people who are best positioned to deal with them.

All that and he is approachable as well. Who thought that bugmeister is just another really technical job is wrong, it also needs someone with social skills.
Thanks,
      GerardM

A message from the #MediaWiki #bugmeister; HELP is welcome

The role of bugmeister has been filled at the Wikimedia Foundation and, he certainly means business. There have been mails with suggestions and discussions on improving the process and now there is a call for all you MediaWiki developers to get involved in the sprint to make release 1.17 ready for release.

The impression this gives is wonderful. Wonderful because it invites people to get involved and stay involved. It gives the impression that contributions are welcome and that there is even someone ready to leverage the power of the many developers who do not yet have commit access as well.

What is also shiny is that by using terminology like "sprint" notions of agile project development come into focus. I am not advocating a new MediaWiki release every four weeks, but having four or more releases a year will be less stressful then the current waterfall of functionality that is in release 1.17.

So check out the list of open bugs and help us get properly ready for the next release. There is one fringe benefit for a good relation with the bugmeister... your JavaScript has to be upgraded next. You might as well get your feet wet now.
Thanks,
       GerardM