The #MediaWiki #GeoData extension is a #dinosaur

"This extension adds a new parser function, {{#coordinates:}}, that saves coordinates to the database. Function's input format is made as compatible as possible with GeoHack".

What it does is save data for one Wikipedia article at a time. It links it to another dinosaur, GeoHack, and hopes for best results..

For as long as such dinosaurs are aliveish and kicking, it may be good. At the same time, it provides an excellent target for harvesting all this geo-data and include it in Wikidata. That will make the same geo-data available to all articles in any Wikipedia on the same subjects.

GeoData saves its data to "the" database, when it decides to evolve and store its data in Wikidata, it may have some future after all.
Thanks,
      GerardM

#OpenDyslexic provides support on the English #Wikipedia

Today the "Universal Language Selector" premièred on the English Wikipedia. There is a ton of functionality in there and it has a lot of potential. The one thing that may prove to be a game changer for people with dyslexia is the inclusion of the OpenDyslexic font.

Once people with dyslexia start to adopt this font, chances are that they can actually read/use Wikipedia. A lot of people are dyslexic; to quote the en.wp article on the subject: "It is believed the prevalence of dyslexia is around 5-10 percent of a given population although there have been no studies to indicate an accurate percentage".

The one thing left to do; let people know that Wikipedia has improved usability for people with dyslexia. Please tell it to the teachers, the parents and most importantly to all the people you know who are dyslexic.
Thanks,
      GerardM

NB it is also available for many other languages on many other Wikis.

#OmegaWiki supports #OpenDyslexic

#OmegaWiki aims to be useful as a platform. Much of its functionality is in the extension that allows us to be special. The core functionality however is provided by MediaWiki. The Universal Language Selector is an extension of MediaWiki waiting in the wings to become available on all the wikis of the Wikimedia Foundation.

Part of the ULS is the use of webfonts and, OpenDyslexic is a font available for many languages that use the Latin script. Languages like English, French, German, Dutch... The font looks odd to most people but for many people who are dyslexic it makes text actually .. readable.
Thanks,
     GerardM

Playing the Wikisourcerer

For any #Wikisource, the proofread page extension provides a must have functionality. Given that it is used on every Wikisource, it is reasonable to expect consistent functionality. The screenshot below shows the the proofreading page for "Noodlot" a book by Louis Couperus. As you can see, the page numbers are in blue or red and they show the classic MediaWiki behaviour. When you compare this with any index page for proofreading on the English language Wikisource, you will find the numbers in multiple colours indicating its position in the proofreading work flow.

As Wikisource is primarily a workflow environment, it is crucial to have a complete implementation of the tooling. When asked, it was indicated that many of the small fixes happen exclusively on the English Wikisource. This lack of support for the proofreading extension elsewhere is an additional argument for doing away with all the single language Wikisources. When one Wikisource provides adequate tooling for the workflow, another wiki can be used to publish its finished content.

A Wiki publishing content in a final form can publish on behalf of any and all open content project that create finished products. Such an expanded project where finished content is marketed to our public will achieve multiple goals:

• it will make finishing projects more attractive
• with an enlarged catalogue it will attract more public
• it helps us achieve what the Wikimedia Foundation is committed to

Thanks,

      GerardM

#MediaWiki #Localisation update process runs now with #GIT

Tthe #Wikimedia Foundation embarked on the migration from SVN to GIT and it proved quite an adventure. It was unclear how changes in the MediaWiki software and its extensions would end up in translatewiki.net . It was unclear how changes in the localisation would end up in GIT and from there on the production wikis.

We are now happy to report that the pipeline from new and changed messages in the MediaWiki software and its extensions resulting in new and changed localisations in all the WMF projects is working again. The messages that have been localised are now automatically moved into GIT and from there the LocalisationUpdate process makes them available in all the WMF wikis.

When you had the LocalisationUpdate process running on your wiki, it is likely that you need to update the software to reflect the change from SVN to GIT. When the latest version of LocalisationUpdate does not work for you, please create a bug in Bugzilla and ask for support.
Thanks,
    GerardM

#WebFonts on #Wikisource

As the #MediaWiki Webfonts extension has been implemented on the English language Wikisource, it provides all kinds of opportunities. What it does require is that you understand how things work.

There are a few things that are important:

• All web fonts are available where WebFonts is enabled
• When a text is properly tagged and a font exists the web font will be triggered
• People easily recognise different languages and different scripts. It is computers and search engines that really benefit from proper tagging. By inference our public does.
• As more freely licensed fonts become available for more scripts, including historic languages and scripts, the user experience of projects like Wikisource and Wiktionary will greatly improve

The Amiri font, a wonderful font for the Arabic script, recently became available in WebFonts. As it is so much prettier then the default font that exists on so many computers, I added the necessary tags to trigger Amiri as an example on one article in en.wikisource. What made my day is that the Wikisourcerers improved on what I did and have the English and Arabic text of the national anthem of Saudi Arabia side by side.

Thanks,
      GerardM

#Wikipedia #help text is written all too often

A great help text is a help. Potential problems with help texts are legion:

• they may not exist
• they may not reflect the current functionality
• they may not exist in translation
• a translation may not reflect the latest original
• it may be badly written
• trying to be everything to everyone
• high on terminology low on easy words

When the help text for the WebFonts extension was written, it was written for users. Documentation <grin> that is help text for developers or implementers </grin> already existed for quite some time. What we learned was that documentation did not help the people who use it.

What we produced solves some of the issues; 

• the original text being written in a Wiki 
• the documentation reflects the software that is in production
• translations are created with the Translate extension; this allows for easy maintenance when changes occur
• translations will be shown when they exist

Help texts exists in many places. It would be good when these text are merged into the central documentation. When the functionality of MediaWiki is supported centrally, it means that developers may take an interest as well. It becomes more obvious to include "stories" where a user understands the latest functionality after reading the help text...

When we agree that help text helps, if follows that help text needs to be up to date and accurate. Writing help text in a central place and translating the help text centrally should therefore be obvious.

Thanks,

      GerardM

Testing the #MediaWiki visual editor ... with #Russian

When you follow MediaWiki development, you will be eager to test the visual editor. A very alpha version of the software is available for testing and, at this time it allows you to enter a text in the Latin script.

That is to say; Amir found a way to enter text in Russian. He uses the Mozilla transliterator. He types Latin characters and Firefox transliterates it into Cyrillic. For Amir the transliterator is a must have feature.

Without it i couldn't write an email to my sisters, comment on Russian blogs or write in the Russian Wikipedia. (You can quote me)

I am happy to quote him and share with you how he sneakily tests the visual editor in Russian anyway. As you can see many more languages are supported in this way.

Yes, your bug reports are eagerly awaited ...
Thanks,
       GerardM

This is on the same #Wikipedia main page

The Malayalam language can be written in many writing styles, most people prefer the traditional style while others opt for the modern style. The modern style was developed to enable typewriters and printing and as such it has been hugely important to bring knowledge to the people of Kerala.

With modern digital technology the restrictions of the previous technology no longer apply. Wikipedia can be in either style because with WebFonts it needs to be no more then a matter of preference. In Linux you will be provided with the traditional fonts by default while Windows tries to be more modern.

WebFonts are a MediaWiki extension that can be applied in many ways and for many reasons. For Wikis we have identified six user scenarios so far. The bet within the Localisation team is that the community will come up with more/less then three additional user scenarios. We expect however that these scenarios can be happily accommodated with the functionality we are currently writing specifications for.
Thanks,
      GerardM

With #agile #documentation can be a product

The #translatewiki.net community provide essential services to the software they localise. Without them the usability in other languages is gone.

The code will not make things obvious because localisers do not read it. To get the message, it can be vital for the message to be documented. This prevents misunderstandings and consequently "user errors".

For all these reasons we are happy to say thanks to Aaron Schulz for documenting the FlaggedRevs messages. This software is quite abstract and this will make the life of our localisers so much more easy.

Yes, it may be that you can do with less documentation with agile. However, when processes rely on the availability and the quality of documentation, documenting means serious business.
Thanks,
      GerardM

MobileFrontend is #MediaWiki release 1.17

The  #mobile gateway has been replaced and it is running live. What is relevant is, that Wikipedia runs MediaWiki release 1.17. This is a patched version of the official release but it is release 1.17.

This factoid is relevant for people running their own MediaWiki project. It is more then likely that they can benefit from native support for mobile phones as well. When you consider how fast mobile traffic of Wikipedia is growing, it is a potential boon for any and all MediaWiki projects. It starts with installing the MobileFrontend extension and there may be some configuration issues to tackle as well.

We may all have wish lists for improved support for mobile phones. What I would like to see is something like the Djatoka software . I blogged about Djatoka in March 2010 however there are other similar solutions. It only sends images sized to fit on a screen. Given the cost of mobile bandwidth, it would be a money saver for our readers.
Thanks,
       GerardM

#MediaWiki Babel scheduled to go live

Translatewiki.net has supported the Babel extension for a long time now. Practically everyone who contributes has this information on their user page and the projects someone contributed to is added as well.

The big advantage of the Babel extension is that it works without templates and that new messages are available every day with the LocalisationUpdate.

Several projects have requested the implementation and, when Babel becomes generally available, it will be easy to add relevant information on the user page without the painful copying of a zillion templates.

With the implementation scheduled for September 21th, this is surely happy news.
Thanks,
        GerardM

#WebFonts for #MediaWiki is maturing

WebFonts, the MediaWiki extension that makes those languages readable that you do not have the fonts for, is surely getting better. Look at these two screen shots; the first one shows how a specific font can be selected while the second one shows the result.

What you will notice is that the support for the different scripts under Linux is adequate. The texts in the different languages shows properly. The Yunghkio font however does not do the Myanmar language justice as you can see in the result below. The text in Myanmar is not properly rendered.

Now that we can show multiple web fonts on the same page, the next phase will be to default to a font when a specific language is indicated. This will be the default scenario for making use of web fonts in MediaWiki.

At this time it is the WebFonts extension that allows for specific behaviour that benefits someone who is visually handicapped. The size of the characters and also the colour of the characters can be selected. Consensus has it that this should be available from the preferences and consequently it needs to move into MediaWiki proper.
Thanks,
      GerardM

Non-Roman character set localization

From a localisation point of view, the least of our worries are the character sets. The person who works on the localisation of software has the ability to read and write his language and consequently the associated character set. The problem with character sets are the readers and writers who have problems with displaying the characters we present to them.

To make this situation even more poignant, character set problems exist for the Roman character set as well. On this blog you may have read about problems with languages like Romanian and Lingala. These languages are written in the Roman character set.

As the Wikimedia Foundation has it on its Non-Roman character set localization page, there is a need for a toolset that supports character sets, fonts and input methods. We are really fortunate that such a toolset exists.

These tools are not created for the Roman character set, but they will be equally effective. They are Narayam. a tool that provides input methods and WebFonts a tool that provides fonts on those devices that are smart enough.

These tools provide functionality in their current incarnation that is basic and essential. Both tools can be improved upon as they can be perfected with increased usability and functionality. However, perfection is the enemy of the good when we are to wait for this. With this basic functionality in place, we can build a vast array of input methods for many languages, we can work to complete or create freely licensed fonts. We will even make a visual and obvious case to the manufacturers of devices that they need to provide web fonts when they are to sell in markets where fonts are an issue.
Thanks,
        GerardM

The UploadWizard became the default upload tool

#Usability is one of the key concerns for #Wikipedia and #Commons. Many people have complained loudly about the old process for uploading pictures and if it was not for the bot uploads, we would not have 10 million image files.

The development of the UploadWizard is at an end. It is now for the Wikimedia communities to embrace the new UploadWizard. The old upload functionality is still there for those who are set in their ways.

Obviously, now that the UploadWizard will get hammered, there may still be some issues. Please use the feedback functionality as the developers are still very much in the swing of things. When your user experience is a bit chequered in the language department, you can complete the localisation at translatewiki.net.

I feel confident that you will love the UploadWizard. It will bring our next 10 million media files a lot closer.
Thanks,
      GerardM

#Commons has an UploadWizard II

The UploadWizard is a WIP, a "work in progress". It is functional and sometimes it breaks. Typically it breaks nicely; it may for instance not show the thumbnails and in some places it is incomplete; it does for instance not yet support RtL languages.

It is however at a stage where the developers want the software to get a hammering. One of the best indicators for this is that there is now software producing statistics for its use. One of the aspects they are looking for is the use in different languages.

To get people to use the UploadWizard in other languages, it needs to be localised. As always translatewiki.net is happy to welcome any new localisations including ones for the UploadWizard.

On Wednesday a new version of the UploadWizard is scheduled to go in production. This means that today's efforts will likely be available tomorrow. For many languages the localisation has already been completed. Please use Commons in your native language and tell us about your experience by providing feedback.
Thanks,
       GerardM

For the #Odia #Wikipedia, editor retention is a luxury problem

When a Wikipedia has 700+ articles, when the most often used messages are not localised, the first order of business is to get more editors. Editor retention has a face; it is could be ଜଗଦୀଶ ଉତ୍ତରକବାଟ retention. Every loss is felt and every Odiya editing newbie is celebrated.

As more people speak Odia than Dutch, it is quite astonishing that a language can be languishing like this. Lately there have been people taking an interest, the percentage of localisation for the "most used messages" has gone up, seminars have been given, input methods are included in Narayam and web fonts in WebFonts.When you add all this up, Odia is a little behind where most new Wikipedias start. With all this in place, Odia is on a level playing field.

The WebFonts extension has not yet been reviewed, it runs in a test environment at translatewiki.net. The Narayam extension runs in production for the Malayalam projects; a requirement has been expressed to prettify the user interface. There are instructions, hopeless for a person who is not confident with computers, on how to install fonts and input methods.

So here is a challenge; as the or.wikipedia is barely alive and as its community trusts the Indian developers who wrote these two extensions, we could install them just on this Wiki. It will accelerate the development and it will invigorate the Odia Wikipedia.

An experiment like this is likely to get us attention in the newspapers that serve a population of some 45 million people. This will get us people who will start off with being curious but who can help this project over the 1000 articles mark.
Thanks,
      GerardM

#Annotations at #Wikimedia #Commons and more

There is a lot of #JavaScript, #CSS and what not that does all kinds of nifty things. The annotation functionality on Commons is a great example and this picture of Zagreb illustrates it well.

It works well up to a point. The point is Commons, the small picture representing the real thing. Annotations you want in high resolution as well. The same annotations would also be quite useful in your Wikimedia project.

There are many hacks as useful as this one. They represent functionality that people grow easily accustomed to and and fill a need so much so that they often move from project to project. Examples like the Babel templates and the input method JaveScript have done this. Having the templates and all the different JavaScripts is not only a maintenance hell it is also a recipe for substandard functionality.

With over 800 Wikis, it is practically impossible to maintain all the templates, the scripts, the CSS. Particularly functionality that has a global application needs to be replaced by maintained code. There is no reason I see why Narayam is not in production where it is needed. There is no reason why all new projects struggle with Babel template when there is an extension doing the same job for years.

Extensions can be replaced when there is a reason. Waiting for perfection is the enemy of the good that current code can provide to us.
Thanks,
        GerardM

Different characters for #MediaWiki

These screen shots say it all; different characters. Different characters because a different font can be selected.

This functionality is of use for all scripts, even for the Latin script because the fonts people have on their PC does not necessarily show all the characters used in a specific language.  By providing a web font, we can make sure that all the characters are available for people to see.

The great thing of this extension created by Santhosh is that it will be of universal use. It will enable people to read our content as long as there is a free font that we can use. For many of our Wikipedias this will dramatically extend the reach of our projects. It is one of the key improvements when we are to increase our reach in the "global south".
Thanks,
       GerardM

PS the code for the extension is not not in SVN yet because Santhosh does not have commit rights.

Narayam live on the #Wikimedia #Malayalam projects

"Bug 27949 - Install Narayam extension in Malayalam wiki projects" has been upgraded to the status of "RESOLVED FIXED" today. 

The input methods that are supported by Narayam for all the languages it supports are now available on all these projects. When nothing exceptional happens, Narayam will be turned on on every Wikimedia wiki next week. 

Narayam is the first MediaWiki functionality written by a developer from India. While its primary aim is to help Indian people edit in their native language, it will evolve into a tool that will be beneficial to editors from every language.

A big thank you to Junaid PV and Shiju Alex for making this happen and a big thank you to Roan and Trevor for taking it into production.

Thanks,

      GerardM