#Monuments of #Switzerland

The problem with #data is, how do you keep it all up to date. For the monuments of Switzerland much of the data is kept on the toolserver. It works just fine.

Wikidata has matured enough to include much if not all of that same data. Missing in the official functionality are the tools to make use of it. Yes, you can store information on the connected Wikipedia articles but that is not the same as using it to administer a project like Wiki loves Monuments.

Un-official functionality meanwhile does provide much of what is needed. This is a list of all the monuments known to Wikidata in Switzerland. I added 86 pictures to the Wikidata items using the WD-Fist functionality.

As more tools get connected, these tools are increasingly attractive to use for a project. One big advantage of Wikidata is that you do not need to have an article for every monument you know about.
Thanks,
     GerardM

#Wikidata - the building of the Nationalbank in #Bern

The building of the Nationalbank in Bern is a monument. It does not have a Wikipedia article and yet, it is known to Wikidata.. When you check out the external source, you find that the source is running on the Toolserver. This probably means that this tool needs to be migrated to labs in the near future.

The database is on the Toolserver probably because of Wiki loves monuments. When you look at the data, you find that among other things it refers to a list on the German Wikipedia. You will also find that much of the data can be included in Wikidata. When all the data is hosted on Wikidata, it is not even necessary to migrate the data to labs.

When monuments like this building have their data on Wikidata, it will make it easier to integrate Commons in Wikidata. As you may know, this is scheduled for the second half of 2014.
Thanks,
      GerardM

Magnus, master of #Wikimedia #tools

When Magnus agreed to answer some questions, I wanted his answers to have impact. So I asked a few influential people what they would ask Magnus. I am happy both with the questions and the answers; they offer us plenty opportunities for making more of an impact.
Thanks,
      GerardM

Lydia: what's his next cool hack

Technically, since the moment I received these questions, it would be AutoLists. 

I haven't decided what to do after this. There is the prospect of extending/rewriting the Free Image Search Tool to use Wikidata, and to suggest images for Wikidata from the various Wikimedia projects in return. 

Also, with the long-term plans to use Wikidata, or at least its software, to finally get a grip on metadata for files on Commons, it might be interesting to create and seed a database for the "obvious cases", which could then in turn seed "Wikidata Commons", when it finally shows up.

Lydia: and what he'd like to do but doesn't get to (so others can do it)

A million things! Many of my tools could do with some fixing, code review, extension, you name it. If you can code, have a look at the existing tools and maybe sign up for a tool or two which you would like to improve (not just mine, of course!). 

I still have to port tools from the toolserver. Have a look here at tools to port and, help me prioritise! 

Another thing I had started back on the toolserver was a "tool pipeline", where you could chain up tools so that the output of one tool is the input of the next. This could be quite powerful, especially for less tech-savy users who can't write their own glue code, even if the concept sounds uncomfortably like the human centipede ;-) Have a look at my attempt back in 2012.

Brion: What's the awesomest tool you've created that people don't (yet?) know about?

That's a hard one, as I carefully and thoroughly spam the community for every new tool I create ;-) 

One that is probably less known, and that I use myself on Wikipedia, is a special CSS for wide screens, where it shows the Wikipedia main text in a central column, and arranges TOC, infoboxes, thumbnails, and small tables on the left or right. Screenshot & CSS

As for actual running code, less known but with huge potential IMHO, are live category intersects on Wikipedia. Together with [[User:Obiwankenobi]], we came up With this: Screenshot JS

Brion: What's the best way to make things happen? (getting cool projects done, even if nobody else is working on them yet

Have something to show people. Even if it's little more than a mock-up. Even if it's full of bugs, slow, ugly, fails half the time, and does only 1% of what it should do. A single thing that people can see and click on can get people to the cause, where a hundred pages of text will not. Stallman's GNUpedia existed on a mailing list with many a fancy idea; Wikipedia was there to see, to "touch", to edit. Even if it was a single, bare Perl script.

Alolita: what are your recommendations are for the next 5 innovative tools WMF needs to fund to build for Wikimedia websites

Not sure about funding for tools; coding projects big enough to fund should probably be designed as Wiki(m|p)edia-default extensions, or even MediaWiki core. In terms of new functionality prioritised in-house beyond the current scope, these would be the most interesting ones for me:

• OSM integration. This has been on the WMF back burner for years.
• Commons file metadata as Wikidata. On Wikidata itself, or added to Commons itself.
• More data for Tools Labs. View data so that we can support GLAM projects; there has been some talk about this lately, but it has been a few weeks away for years now. Also, faster access to the wikitext than through the API/dumps would be useful.
• Add Wikispecies to Wikidata. It might revive Wikispecies (which seems sadly underused), or at least rescue much of its information onto Wikidata.
• One old pet idea of mine: Wikimedia (bi-)weekly magazine. Consider an amalgamate of Wikinews (which, let's face it, has pretty much failed as a daily source of news), Wikipedia "did you know"-type interesting articles, interesting places from Wikivoyage (which appears to be booming), fascinating images from Commons, an excerpt from Wikibooks, a short story from Wikisource, you get the idea. An editorial text, or political comment (relevant to the Wikimedia world; think CISPA), from individuals might not be too far fetched an idea. An issue would be generated in the usual fashion, maybe with an editor-in-chief (rotating? elected every three months?) to address the time-critical nature of the project. A completed issue would then be generated in several formats; on-wiki, PDF, etc. Maybe even go through proprietary distribution channels like Amazon or Apple, if the license situation allows it. I am sure tablet users would flock to it, and we might get some of these "consumers" to participate in one of the Wikimedia projects, maybe with "photos by readers" as an entry-level drug :-)

Alolita: How WMF can help support the development community better * process recommendations * policy recommendations * participation in helping grow more developer contributors

I'll answer these as one question. For tool developers, Labs is already a fine solution. There are a few rough edges which could be smoothed, though; "find someone on IRC" is often the way things are done, which is not always the best. There were a few outages recently, which can happen, and it took hours for someone to have a look a the issue, which is not exactly a life-or-death situation, but still frustrating for tool authors, and not just because of "your tool is broken" messages piling up around them. I understand that only core systems can have someone on standby 24/7, but maybe Labs issues could bubble up the chain automatically if no one from the usual Labs crew is around. 

Getting more people to make use of the great Labs facilities is important. Part of that could be a simple visibility issue: if more people knew that Labs offers not only CPU and storage, but live mirrors of the Wikimedia databases, or that they could easily help fixing or improving that vital tool, we would probably see more widespread adoption of Labs by programmers. Labs-based git repositories for each tool could also enhance visibility, and improve code reuse (which I practice heavily within my own tools). 

In terms of adoption of tools and extensions by volunteer developers into Wikimedia wikis, MediaWiki core itself, or as stand-alone systems, clear and time-limited review procedures would be required, as well as assistance by Wikimedia developers to get code up to MediaWiki standards. On the other end, a public listing with project ideas that, if implemented, would be considered for adoption by Wikimedia, could focus volunteer programmer participation. I am talking about a simple list of "we would like to have these, but don't have the manpower" issues, written by Wikimedia staff, as opposed to obscure feature requests in bugzilla that might be long obsolete.

Open source is also to work together on software, tools. Your tools are available, how do we get more people to cooperate on them

By refusing to fix bugs, we could force the bug submitter to do it ;-) 

On a more serious note, I think improving visibility, as mentioned above, of the great things Labs offers, and that participation on existing tools is encouraged and welcome. Just like many people use Wikipedia but still are not aware that they could edit it themselves, potential volunteer programmers might think that these tools are done by Wikimedia staff, or some carefully chosen group, rather than by run-of-the-mill geeks like them.

When you had someone to work on improving ONE tool; what would you want him or her to do?

Extend Wiri a.k.a. "the talk page". It is not so much a normal, "useful" tool, but a nice technology demo, not just for Wikidata, but for a confluence of technologies (data from Wikidata, speech generation from third-party open source, speech recognition from Google) enables functionality that plays in the same ballpark as big commercial solutions like Siri or Google Now. 

I am well aware it will never be en par with the Mathematica/Wolfram Alpha backend in terms of calculation power, or up-to-the-minute sports results. But even simple improvements, like a listing of options if the (speech) input is ambiguous (e.g. several people with the same name), translating complex questions into Wikidata query requests, displaying images, maps, or using AutoLists to show multiple results, could turn it from a mere demo into an actually useful tool. With proper, fault-tolerant grammar parsing, real reasoning, and the ability to explain the reasoning, it could be amazing!

It is all about #presentation

The edit screen of #Wikipedia' is similar to the standard screen of #Wikidata: it is ugly and it does not present the data well. Look for instance at the two screen shots. The same data about the "office held" by Mohammed V of Morocco is available in both screen shots.

The screen shot above is the standard screen of Wikidata for Mohamed V. The screen shot below is the same data formatted by "reasonator".

There are issues with the reasonator. When you compare the data you will miss the second term in office as Sultan of Morocco. There are other bits of information that are formatted in a weird way. But that is not really important. What is important is that proof of concept tools like the reasonator and the geneawiki motivate me to enrich an item with statements.

PS I really got into the reasonator when I learned how to add a picture.
Thanks,
      GerardM

Cleaning up the #MediaWiki namespace

Your #Wikipedia may have many messages that can be safely deleted. Robin created just the tool to inform you what messages can be safely deleted because they are identical to the ones provided to you by MediaWiki.

These are identical messages on the Marathi Wikipedia that can be deleted because they are exactly the same. This is a job that any local admin can perform. It will make sure that when a message is changed, the updated message will become available. There is even a list that can be used to have a bot delete these messages; this may save someone from a lot of boring work.

Really interesting are the custom messages; they are the ones where the local message differs from the message provided by MediaWiki. They come in two flavours:

• Messages that are correct on any Wiki and should be included at translatewiki.net
• Messages that are specific to this Wiki

When the messages that are correct on any wiki are included at translatewiki.net, they will become available within a couple of days thanks to the LocalisationUpdate process. At that time these messages can be safely deleted.

Thanks,

      GerardM

#Plural for the #Toolserver

We are used to the support for the plural form in #MediaWiki. Without plural support the localisers at translatewiki.net do ask questions.

Learning that Jan Luca has written plural functionality for the Toolserver I18N-framework is therefore very welcome news. It is not yet in production because he wants a second pair of eyes. Krinkle has given the code a first glance over and he promised to have a good look this weekend.

With better internationalisation support, it becomes increasingly worthwhile to make Toolserver tools ready for the international audience that is our Wikimedia community.
Thanks,
       GerardM

CommonsHelper2 is there for you

When tools are available in your language, it is much more likely that you actually use them or recommend them to your friends. What is nice about this tool is that it just does something and consequently should work well in any language.

The tool did work in Hebrew in the past so it is extremely likely that right to left languages like Arabic or Persian will do equally well. As many people feel more comfortable uploading locally, hopefully many pictures will find their way to Commons this way.
Thanks,
       GerardM

#SVG maps that beg for a translation

The #Malayalam #Wikipedia Map project provides great maps. When you want to illustrate something to do with these Kerala districts, they provide the perfect canvas. It is a labour of love to make these maps and there is even more mileage that can be had with a slight change.

The slight change that would make these maps awesome is by making all the texts into separate labels. This provides several opportunities:

• you can translate the labels in other languages, to English for instance
• the maps will become usable on even more Wikipedias
• you can use the map without the labels as a canvas for other purposes

Once the names are available in labels, SVGtranslate  is ready to translate the updated SVG maps. SVGtranslate is one of the Toolserver tools that can be localised in Malayalam at translatewiki.net.
Thanks,
      GerardM

#Toolserver - Magnus Manske

Of all the #MediaWiki developers, Magnus has a special place; not many people can claim their day, for Magnus it is January 25 when his achievements are celebrated.

After initiating next generation MediaWiki, he very much remained involved and he became the king of the proof of concept on the Toolserver. That is to say, he develops working bare boned functionality that scratch an itch.

Once the itch is scratched, he happily leaves his tools for others to embellish and perfect. Revisiting code to implement internationalisation is not his thing, having internationalisation as part of a new project is different. When I blogged about CommonsHelper2, I did not know that Magnus conceived the original version of this tool and to be honest, I did not really care. I care about good open source working methods and the internationalisation of code.

It was pointed out to me that Jan Luca had taken over the maintenance of some of the tools of Magnus. Speaking to Krinkle, I learned quite a bit about how Toolserver is changing, actually improving.

One recent novelty are the "multi-user repositories". They allow multiple people to work on the same tool. This allows Jan Luca for instance to implement internationalisation in CommonsHelper2.

Another thing that is quite relevant is that the barrier to entrance is relatively low. You can have a developer account in a matter of days and publish tools in days. Compare this with the process of getting a MediaWiki developer account...

Even though Toolserver provides important functionality, what it offers is not that well known. It is very much a geek / hacker haven. Promoting tools that are ready for localisation is something that has its place on this blog. Calling out for developers who may be interested in bringing existing tools to a next level, tools by people like Magnus or Daniel are also of interest.
Thanks,
        GerardM

CommonsHelper2 by Jan Luca

The #Toolserver tools most desperately in need of internationalisation and localisation are the ones that serve language communities to bring the best out of what they have locally.

CommonsHelper2 is a tool that helps move media files from a project to Commons. Once media files are on Commons, they can be shared not only among all the Wikimedia projects but also by those MediaWiki wikis who have enabled the use of files available on Commons.

The current version is already available in two languages; English and Hebrew. Having it available in Hebrew enabled a much easier transfer of media files from the Hebrew projects. Once the localisations for this tool get under way illustrations that were so far reserved to a local wiki will get a much bigger audience.

Today the first messages became available in SVN. Jan Luca and Krinkle will have to work on the final touches to make yet another relevant tool ready to attract users from all over the world.
Thanks,
      GerardM

A #Toolserver heaven

When God created his first code, he created it in his image. He put in his own repository, called it Open Source, announced it to the world and walked away to do another creation.

Many of the Toolserver tools are abandon ware. They have been thankfully received by the mere mortals who pay daily homage to the Gods by evoking the code in a quest for reaching the heaven of enhanced and divine effectiveness.

As more mere mortals scaled the heights of tool proficiency, their understanding became fractured as more of them started to talk in different tongues. The code lived on and everyone was still expected to continue building the tower that brings knowledge to all of humankind.

The Gods did send their sons to update much of the code; even though the code was in many books, the revelations could be extracted into a single source that would be delivered to the mere mortals. As these new levels of understanding descended on the faithful, the code itself remained a testament to the original structures and coding practices.

The promise of new coding practices descended on the disciples, they theorised and promised an afterlife where all the code will work to its full potential. Code enshrined for all to see and improve upon.
Thanks,
      GerardM

Bringing a #Toolserver tool to the next level II

The #SVG translate tool is developing nicely; my pet peeve has been sort of solved. It now uses the Toolserver User Screening Control which is a tool that allows for checking if a user exists on a Wiki.

At best TUSC is a crutch;

• it seems not to be aware of SUL
• it introduces a new user with a new password
• it clutters your talk page with some necessary gibberish
• the upload is done by a bot anyway

The origin of all this is that the Toolserver is not a Wikimedia project with all its save guards. Add to this that while Wikimedia has SUL, it does not provide authentication services for Wikimedia movement projects like Toolserver. When MediaWiki were to support openID, we would not need additional passwords and have implicit authentication outside of the Toolserver.

This software already exists for MediaWiki for years.

The upload functionality however does work. Now for an invitation to do more localisations; maybe the template can provide information to find more untranslated SVG graphics.
Thanks,
       GerardM

Bringing a #Toolserver tool to the next level

#SVG translate is a lovely tool, it does work as advertised and I can use it in my own language (click here when it is not yet available in your language).

It is good, it is a big improvement and there is room for improvement. The work flow of an SVG image goes something like this:

• find an SVG image with translatable labels
• find the tool to translate the label
• translate the labels
• check out the SVG with the newly translated labels
• upload the SVG to Commons

As the time it takes to translate is quite minimal, translating more images is an easy option when the other parts of the work flow are equally efficient. When the tool is aware of images waiting to be translated and prompts you, why not do another one?

This would work well when there is a magic formula to evoke the upload wizard. A formula can be found because a translated image is after all a derivative work. All the information of the original applies and the only thing left is to credit the translator. With the upload wizard ready at the end to make all the translated images available it would be heaven.
Thanks,
      GerardM

What #Toolserver tool will be next?

At #translatewiki.net the localisation of Toolserver is quite popular; it is not even 24 hours yet and the localisation for several languages is complete. There have been fourteen people active for their language and there are many more languages to choose from when selecting a language on the Toolserver.

When you follow the "MediaWiki CVS" changes, you may have noticed that there has been a steady trickle of improvements to the functionality. Krinkle is doing a great job for us.

The one particularly pleasing thing is the amount of effort that went into the documentation. The intention is to have a quality of such a standard that any Toolserver developer can implement internationalisation for a tool.

Krinkle is quite happy to give a helping hand to the early adopters because that will test the quality of both the software and the documentation. The question is how many tools will be ahead of his "recent Anonymous Activity" tool.
Thanks,
      GerardM

#Toolserver tools are ready for #localisation

At #translatewiki.net, the first Toolserver tools are now ready for localisation. This provides improved accessibility to tools that have proven themselves to those people who are happy to work with English language tools.

The process of getting the messages live is similar to how it is done for MediaWiki. The localisations will be checked by the translatewiki managers and after this they will be uploaded to SVN.

When a tool makes use of the "Intuition" localisation, cookies will be set remembering your settings.

All "Intuition" tools will make use of these settings. This means that even newly localised tools will know what to do. Fall back languages are defined in the same way as they have been for MediaWiki; this means that Ossetic for instance will fall back to Russian.

When your first contact with localised tools is by using it, you will be prompted to the possibility to set your preferred language. As always we welcome anyone to help us with localisations at translatewiki.net; your work puts tools in the hand of people who will become more effective as a result.
Thanks,
       GerardM

When you develop a tool, you test it

The #internationalisation for #Toolserver is being developed at the moment. This means that making tools ready for localisation is the experience that shows if the architecture works as designed.

One of the tools that is getting TLC as a result is OrphanTalk. This is a tool that shows talk pages that are no longer connected to its page. The tool is quite popular but its lack of localisation prevents it from becoming more popular.

Krinkle, the developer of the internationalisation tool, indicates that he intends to release often and early. The first release will allow localisations to be prepared at translatewiki.net and be used by compliant tools. The next phase will allow for functionality like the expression of plurals.

But first, getting it in production at translatewiki.net.
Thanks,
      GerardM

Hopes are up for #Toolserver II

No tool is more appropriate then "#SVG translate" to be the first of the Toolserver tools to be internationalised. This tool that has been around for quite some time and was recently adopted by Jarry1250. He came to #mediawiki-i18n to learn how to get localisations for this tool.

One of the things that is quite nifty is that it does not only enable translations for the SVG files at Commons, you can also translate files from other websites.

With Jarry1250 and Krinkle setting up the internationalisation for Toolserver tools, the functionality of SVG Translate got attention as well. The image that has its labels translated is now shown together with the labels that need translation.

There is some Dutch in this screen shot :)

With the usability improvements and the accessibility improvements SVG translate has the potential to become a tool that will seriously support the use of SVG in all the Wikimedia projects. A tool like this unlocks an potential that has been inherently present all the time.
Thanks,
      GerardM

Hopes are up for #Toolserver

With Toolserver effectively an English language only project, its use is limited. This is sad because many really useful tools are based at Toolserver.

Krinkle has written to the Toolserver mailing list that he is working on I18N for Toolserver tools. This raises expectations. In this mail he is asking people to help him come up with a name for the tool, for the user that will be used to run the program.

I am intrigued by this system because it is to be super easy for developers. There are however two groups of developers involved; they are the developers of the individual tools and they are the developers at translatewiki.net.

As internationalisation is an architecture, it will be interesting to learn how its logic and structures will be fitted in, if there will be support for constructs like plural and gender. Even when initially such constructs are absent, it will be a huge improvement for the accessibility of the tools that will be taking their game to the next level.
Thanks,
       GerardM

How #Toolserver can do much more good

The Toolserver is a cluster of servers hosting tools written by many people. Some of these tools provide essential services like the traffic statistics of the collections provided to us by GLAMs.

Every individual tool is experimental and essentially provides a proof of concept. The implication is that once a tool has proven itself, it could go to a next level and gain all the trappings of a production service.

Criteria for the tools that deserve to be upgraded to production quality are:

• the service it provides is being relied upon
• the service can be of value to an international public
• it stimulates the use of the Wikimedia projects by new demographies

Currently none of the Toolserver tools are of a production quality. The tools are in many code repositories and they do not comply with best practices. They are for instance not internationalised and when they are, they are not localised at translatewiki.net. Screens are not designed to take additional data into account.

As these tools are freely licensed, it must be possible to either fork the code or preferably work with the primary developer to provide the service that the concept hints at.

When you consider the size of the Toolserver server park, it is not a project that can be dismissed as "Spielerei".

Thanks,
       GerardM

Indonesian story cloth presented again ..

The #Wikimedia #Toolserver hosts this huge, huge story cloth of the Tropenmuseum demonstrating the technology cobbled together by dschwenn.

The thing I am particularly pleased with is, that I understand that this technology can be used for any of the 6,313,148 images of Commons. All kinds of optimisations are possible, but the sheer fact that this provides an obvious improvement both for computers and mobile phones is what I like best.

Both for Djatoka, the competing technology, and for IIP and VIPS it is not only about showing pictures in the smallest detail. Example uses for IIP are: high resolution museum images, scientific imaging, geographical information systems, medical imagines.. The examples are most interesting.. There are several GLAM related examples like this detail of "The lady praying" from a picture at the Louvre.

The suggestion of using zoom technology for Commons has been around for some time, Kolossos had a demo for Zoomify on his account, but he never worked on making the preprocessing on the toolserver (he had to process the images manually on his windows machine at home, so he basically only ever showed one single image).

As user experience and multimedia usability have a high priority, I hope that this kind of technology will gain its place sooner rather then later.
Thanks,
GerardM