Browse Author by RichardHeigl
Visualization of the Franco-Prussion War
View Post

MediaWiki – Software moving towards the future (Part 3 of 3): Communication, Wikidata, Translation

Communication and notification – the end of the classical discussion pages

Another MediaWiki construction site is delivering good news: The MediaWiki Communication System. This concerns the discussion pages. These will soon disappear, in the form we know them now. More precisely: The discussions pages will fundamentally change and merge with the notification system.

The reconstruction of the MediaWiki communications system will take place through two new extensions:

  • Echo allows the individual following of changes, gives an overview of the whole system and is a framework for a variety of communication services. Echo is already in Wikipedia as a new notification system.
  • Flow makes discussion easier. One can more easily follow discussion processes; answers are shown via Echo. And much more. The aim of these developments is to build up a modern discussion and collaboration system for all Wikimedia projects. An interactive prototype is already online.
The Flow prototype
The Flow prototype

In the end, MediaWiki will have access to a new communication layer, which has long been overdue. It is important to note that the combination of articles and discussions – a characteristic and principle for the success of MediaWiki remains. The articles will not be separated from the discussions which relate to them. The linking of articles with discussions is a basic principle which makes MediaWiki unique, giving it something special compared to other solutions. Flow and Echo can really bring this basic principle of MediaWiki to its full potential.
However, many in the Wikimedia community are sceptical. For them, the current systems is absolutely adequate. Behind this, there is an interesting debate.

Erik Möller writes: “Do we want discussions to take place in a document mode, or do we want a structured commentary mode?”

This is the difference between saving discussions on a page or in a database with other possibilities for sorting and filtering.

Even though saving onto a page has a certain charm – particularly with respect to archiving, it is unlikely that this principle can be maintained for long. The advantages of following different discussions in a central place are convincing and overriding.

Collaborative data collection – Wikidata & Friends

A further signpost to the future is the development of collaboratively managed databases. The project OpenStreetMap is already well known, and creates map material using the wiki principle.

Wikidata follows a similar path, a collaboratively managed database. The different language versions of Wikipedia need not only pictures and videos, which are currently collected centrally in Wikimedia Commons. Providing metadata centrally is just as important.

Before, each language version needed to be changed by hand.

 

Excerpt of the Wikidata page of New York City (Original: https://www.wikidata.org/wiki/Q60)
Excerpt of the Wikidata page of New York City (Original: https://www.wikidata.org/wiki/Q60)

 

To provision all Wikipedias and for all use cases, is a very ambitious aim. After all, the data is not included in a homogeneous data schema. The data samples differ enormously by topic and cannot be centrally predetermined. This can only be done by authors. The authors can freely specify the data fields and composition themselves. They can add to new data fields or delete them. This also means that authors need to agree on uniform nomenclature and consistent data management. Further, the sources of the data must be shown so that one knows where a number, name or value has come from.

The effort is, however, worthwhile: One of the next steps will be to display the data better, in order to, for example, show personal connections in politics and history better. This will be significantly easier with Wikidata. For example:

 

Visualization of the Franco-Prussion War
Visualization of the Franco-Prussion War

This will develop, in a similar manner to the project Wikimedia Commons, a publicly accessible store of data, under a free licence, meaning a part of the web’s memory will become open to all.

This development is, therefore, pioneering for the free web. Initially, data will be collected for the Wikimedia projects, but very soon other projects will be able to consider using Wikidata software. For example, when data is to be collected about a specific specialised area which is too in-depth for Wikipedia; or when it is necessary to keep control over the data sets. I am thinking of Lobbypedia or more extremely Wikileaks. This requires protected Wikidata infrastructure, which is kept by a circle of trustworthy people.

The end of the category pages and SemanticMediaWiki?

Alongside the build up of this database infrastructure, another MediaWiki feature will soon belong to the past. We are talking about category pages. Up until now, the category information (indexing) was inserted in the wiki source text. This concept has, like discussion pages, its charm, but it leads to very laborious management in the long term. Due to this, it is likely that Wikidata will eventually replace the category system. The category pages are, however, often also used as practical portals. This function must be maintained. But these are the topics of interest for the years to come, and the discussion has only just started.
This is also true for the future of SemanticMediaWiki. Some see Wikidata as the successor technology on the horizon. For this, though, Wikidata needs to develop significantly as regards implementation and adaptability. And as Semantic needs absolutely no extra technology, and is being driven on by a very lively community, there is no end in sight. It is actually more likely that the Semantic community will anticipate many developments which will only later be taken on in Wikidata.

Automatic translation

Lastly, I would like to highlight another very promising development: Great strides have been made in the automatic translation of content. The extension Translate, which has been in use for a while now, is developing to translate system texts from open source software projects. Henceforth, this function will be extended by a technical translation aid which will already be able to suggest whole text passages as translations and improve their quality significantly because one can use Wikidata. The first versions were introduced at Wikimania 2014 and the end of the second step has recently been announced. Languages are being added one by one and the functionality is being continually extended.

Final thoughts

All these developments are focused on the needs of Wikipedia and possibly on its sister projects. It is, however, necessary to make these developments useful and available in the long term for other use cases and non-Wikimedia projects. For this reason service providers will have to provide the necessary services – from development and customisation up to maintenance and support at a high level.

 

Links

 

The version of the "VisualEditor" currently (September 2014) on mediawiki.org.
View Post

MediaWiki – Software moving towards the future (Part 2 of 3): Visual Editor and simultaneous editing of texts

Visual Editor – Wikicode is supplanted

Anyone who has written or improved Wikipedia articles in the last few years, already knows about the Visual Editor, which has now reached a certain maturity. (See the post by Nathalie Köpff on this subject). Creating such an editor is a big project. Unlike other web applications, an editor for Wikipedia must not only work with different languages (for example right to left languages), but also be able to process the multitude of wiki functions, the template system, the magic words and many more things besides. So for this, the wiki text parser Parsoid needed to get a totally new technological basis. As Wikipedia develops further through web standards (browsers, protocols, languages), the task will remain a complex one for a long time. However, it is also a rewarding project which has significance for the whole web community – as, for example, no commercial provider would develop an editor for over 100 languages and make it available for free.

The version of the "VisualEditor" currently (September 2014) on mediawiki.org.
The version of the “VisualEditor” currently (September 2014) on mediawiki.org.

 

Nevertheless, the project is still controversial in the Wikimedia community to this day. This is partly because the introduction of the editor has lead to significant complications. The editor was simply not ready to use when it was implemented for the first time.
The scepticism in the community towards the editor, however, also has to do with the fact that its increasing use allows for a wide reaching dropping of Wikitext. What, for some, is a good opportunity is, for others, a loss of design potential. As up to now, it was possible to build many small tools with the standard resources (for example templates or overview lists). Even simple formatting is significantly more efficient for experienced wiki text users.

However, over time, Wiki code, which should make editing easier, has almost had the opposite effect. Editing a wiki article needs a certain amount of experience and skill. This is, however, not sensible, as many hand-made functions can be done more elegantly with corresponding extensions.
A great deal of identity and a bit of wiki philosophy is attached to the transition to the visual editor. For some wiki authors, it may be a restriction, but for the wiki world outside Wikipedia, it is a great leap forward. The standard ways of using wikis have changed; most wikis work in much less complex ways than Wikipedia, which has always been a special case with its own particular demands. For this reason, a native visual editor is a long overdue step for many MediaWiki users. It is necessary so that wikis can be used to build up new free knowledge hubs on the web.

Simultaneous editing of texts

A further, very ambitious project was introduced at Wikimania 2014. The aim is to enable the simultaneous editing of texts, that one already knows from Google Docs. This has been considered for a long time. However, the necessary resources for the project were not there. Now, the Deputy Director of the Wikimedia Foundation, Erik Möller, has announced that the first prototype should already be available in a year. This is very exciting news.

Two points are not being discussed at the moment, but could become important in the future.

  • Speech2Text: Texts in wikis should be increasingly possible to dictate. “Speech2Text” is developing into a standard as the speech recognition software has made great strides in the last few years. We will see that speech-control can be performed in Google search.
  • Draft function: On top of this, a real draft function is needed for MediaWiki. Every trust and NGO with local groups needs to be able to develop texts for projects, for example. Up to now, they have been diverted to Google Docs or Etherpad. But these two applications are totally inappropriate for the public collection of knowledge for a number of reasons.
    For this reason there should finally be the chance in MediaWikis to edit a first drafts with just a small circle of authors before the text is released generally.

Overall, we at Hallo Welt! see this development as very positive as MediaWiki will become more user friendly. Using it will be more intuitive and working with the editor more stable. Our enterprise distribution will take these developments on, customise them and make sure they are continually developed.

The "nearby" funtionality in the Wikipedia App
View Post

MediaWiki – Software moving towards the future (Part 1 of 3): Skinning, Mobile, Dialogues

There is a lot happening for MediaWiki at the moment. Further development of the software has been getting recognisably bolder for more than a year. It is getting exciting! In 2015 we will see many changes which up to now have been being worked on in the background. In just a few years, the system will no longer be comparable with today’s MediaWiki. Both the technical architecture and the user guidance is being rethought and tailored to the new expectations of the users. We want to quickly introduce you to the newest development projects.

The new impulses in MediaWiki development come primarily from the Wikimedia Foundation (WMF), the operator of Wikipedia and its sister projects. The foundation sees its core task for the future as software development and is looking to build up its personnel in this area a great deal. The new executive director of the foundation, Lila Tretikov, announced in October 2014 that the majority of investment will flow into product development and software development. Within this, priority will go to building up mobile functionality (for more on this see the entry by James Temple).

Skinning – Improved overview

Normal users will notice the changes most in the design of Wikipedia. The new skin “Winter” will soon be implemented. You can already see an interactive prototype on the web.

 

The Vector Interface Design "Winter" (Version 0.6, 10/2014)
The Vector Interface Design “Winter” (Version 0.6, 10/2014)

 

Clearly a fuller redesign which was envisaged with the skin Athena is no longer being pursued. However, the appearance of Wikipedia and therefore of the standard software MediaWiki will still become significantly better organised, and more modern and consistent. The new design should invite participation, ease processes and give the user better orientation. The classical functions – editing, discussing, compare versions etcetera – are being moved more to the foreground and being better organised. Also, some functions which were more hidden are being integrated more elegantly in the skin.

Wikipedia will be made more visually attractive, and so MediaWiki too, with the extensionMediaViewer. This allows picture sources to be displayed better and larger. Additionally, one can click through the pictures contained in an article.

 

Mobile front end

The MediaWiki developers are not focussing their skinning on responsive design, but rather by offering their own user interface with the name MobileFrontend which will be continually developed further. Where the developments in the mobile area will lead, we cannot say at present. However, we can expect that the editing and maintenance of text, uploads and user communication will be built up.

Read an article with the mobile frontend
Read an article with the mobile frontend

In the meantime, Wikipedia fans have an improvement to the WikipediaApp, which also has a nearby function: By using geographical data, the app shows Wikipedia articles about buildings and facilities in the immediate area.

The "nearby" funtionality in the Wikipedia App
The “nearby” funtionality in the Wikipedia App

On top of this, there is a nice app for the dictionary Wiktionary and one for Wikimedia Commons. Nevertheless, there is still a lot to do. In particular apps for other wikis – including company wikis – will be needed in the near future. We have a first version of the Enterprise Distribution BlueSpice ready. These developments are aimed at the concrete needs of the user.

More convenient dialogues

There are also developments to the dialogues. In Wikipedia, you can already see these improvements when inserting categories, comments or templates. Therefore, the plans for the extension Upload Wizard are very promising. UploadWizard guides the user step by step through the uploading of data and has been developed for Wikimedia Commons. The Wikimedia Foundation’s Multimedia Team are expanding this extension step by step to 2015. In this way, documents uploaded via Wikipedia can be uploaded to Commons simultaneously. Uploading via Drag&Drop is also being considered.

Task: Continuity and integration for businesses and organisations

These are the most important developments for the whole project. We at Hallo Welt! have already pre-empted many features with BlueSpice. Insofar as MediaWiki is now providing tools which fit better into the software landscape, we benefit because we no longer need to continue some developments. We can concentrate on the conception of the enterprise distribution.

However, there is a great deal of work waiting for us here as the new MediaWiki features are in some places not particularly far developed in terms of the scope of the services they provide. They need to be further customised to fit the use cases found in businesses. This is because an enterprise distribution has necessarily different requirements to those of Wikipedia. Our task is to combine the extensions in the right way, to standardise them and to integrate them.

In particular, the WMF developments have the drawback that they are introducing new technology which is little supported by hosts or internal IT departments. Specifically, we mean the webservice Parsoid, a special Wikitext parser; the virtual machine HHVM; and the programming language Luafor template programming.

 

Hallo Welt! aims to provide a continuous and reliable development, alternative solutions and integration so that MediaWiki can always be used productively and in an up-to-date way outside the Wikimedia world.

 

 

BlueSpice, MediaWiki and the outlook for libre knowledge

BlueSpice for MediaWiki is a commercial project. The plan to develop an enterprise distribution for MediaWiki was driven by the aim of making a profit and creating jobs.

Nevertheless, it is time to say a few words about other aspects of the BlueSpice project. For BlueSpice is also a project that should push along the development of MediaWiki and the construction of free knowledge platforms on the Web.

I will consider three aspects here.

1. Wikis are society’s future repositories of knowledge and BlueSpice should make a contribution

An open society needs a place to gather knowledge, to organise it and to map it. In the future we will find society’s memory on the Web. Political Wikis show how important this memory is. Lobbypedia and its English predecessor powerbase from spinwatch are two good examples. NGOs collect information there about lobbyists, politicians and organisations making networks and strategies transparent and making the information available for research. Think Tank Network Research is a similar research project. I could go on and on with this list.

It is not just in politics that we need a central platform on the net where we can collect free knowledge centred on particular themes, but also areas like leisure, culture, sport, business and health. Regional and city wikis have already become the trailblazers here.

And there will be wikis which save content from other websites so that it can be further developed and worked upon.

There is no system better suited to such tasks as MediaWiki software. And MediaWiki has a special role because the software is available under a free licence and, being an integral part of the Wikimedia projects Wikipedia, Wikimedia Commons and Wiktionary, has the best outlook for development.

So that the operators of wikis can carry out their work with significantly less technical personnel and budget than Wikipedia, they need MediaWikis which can be expanded with inexpensive software packages fitting their needs.

So BlueSpice publishes its free version, not only for marketing purposes, but also so the software can make life easier for those involved in such projects.

2. MediaWiki is becoming a software framework and BlueSpice is a step on that road

More and more projects are starting using MediaWiki as a basis and putting further pieces of software on top. With MediaWiki, you can operate an online encyclopaedia. However, if you does not want to do that, you will need another user interface but you can continue to use the basic structure. This means that the basic system stays the same, MediaWiki, delivering authentication, rights management and categorisation. On top of this comes, for example, BlueSpice, making the system into a company wiki.

A couple of further examples:

  • Translatewiki extends MediaWiki into a collaborative translation management system.
  • There is an initiative in Germany, which builds on MediaWiki to safeguard the basic provisions for media. For this, MediaWiki needs a additional layer which can provide and manage films.
  • At Hallo Welt! we are doing something similar, working with the project LinkTank, a collaborative link directory, and with Musikwiki, a place for collecting musical score. In one project one edits music scores and on the other collects links related to a theme.
  • Wikimedia Commons also only needed to further develop the user interface to make a really attractive platform for a picture library beyond Wikipedia.

MediaWiki has a very special role in open source applications. The software is completely unrivalled as a framework for “collecting open knowledge”. WordPress would be comparable as a basis for communication and social networking solutions.

Thus, we see BlueSpice as one of many steps in the development of MediaWiki into a general framework for free knowledge. This process tests out new possibilities and builds up knowledge which can be useful for other projects.

3. MediaWiki needs an ecosystem and BlueSpice is a contribution to this

The most successful and innovative open source software projects have developed a vibrant ecosystem that putting together both non-profit and for-profit agents, each driving the development in different ways. A large circle of developers is created. The software can assert itself over propitiatory systems and even force them back.

MediaWiki has a very underdeveloped ecosystem compared to other software projects. This means that commercial development in the whole project can be put to good use. Many projects need, for example, a user management system in the backend. In this form, this is not necessary or possible for Wikipedia. All others, however, need exactly this extension. Now these were firstly developed for companies and are now available as free software. I could add many further examples from the development of BlueSpice.

We need, therefore, better general conditions and more energy for a MediaWiki ecosystem. It is true that the Wikimedia Foundation has recently invested more money and energy in software development. However, this will not be enough on its own. Even for sister-projects like Wikimedia Commons, the capabilities necessary are often not there. For this reason, the focus is on third party developers and one wants to support the development of a MediaWiki ecosystem.

This is a step in the right direction. The new initiatives from the Wikimedia Foundation, to develop MediaWiki further and to create a new economic setting is bringing new energy to the whole project. This will open up new vistas to free knowledge projects.

Here, BlueSpice is just one cog in the machine. But it can and will be the basis for completely new types of project.

The decision, in the end, will be made by the users and the community.

BlueSpice 2: The new version coming up later this year!

We started with BlueSpice three years ago in October 2010. Since then, we have gradually expanded and improved the software. In the fall of 2013, we are taking the plunge and publishing a completely revised version.

The new version of BlueSpice builds on the experience we have amassed working with public company wikis and user requests and suggestions. But opening up BlueSpice for developers and vendors is also an important step. We took this into account in the planning stage by inviting our users to participate in a feature poll.  The architectural changes below the surface also have this aim.

The schedule: In October 2013, both the beta and the stable versions will be launched. The good news is that most of the changes have already been done. We don´t want to let the release become a never ending story and so we decided on for a timebox approach. It´s better to have one feature less than to jeopardize the release date. Nevertheless, there is a lot of work which has to be done!

 

1. New tools for quality management

Let´s start with wiki contents. With BlueSpice 2 it will become easier to control content quality by using new functions:

  • A reminder feature will let authors add articles to a watchlist and will remind them to review the article after a defined period of time. We will completely revise our workflow tool (Review) in line with this new function next year. This tool will make the workflow process much more flexible.
  • BlueSpice 2 comes with a dashboard for users and administrators to organize their tasks. A feature that’s been eagerly awaited! This central dashboard can be individually filled with different widgets.
  • Extensions which may seem minor will significantly change day-to-day work with the wiki:  We are adopting the new notification system from MediaWiki, which unifies the notification process and makes it clearer. Articles can be added to the watchlist with one click, like in Wikipedia. And last but not least, it is possible to assign a category to an image in the upload dialogue.

 

2. Better usability, faster navigation and a new “State of the art” search function

A lot of things are changing in terms of usability too:

  • Visual editor upgrade: We are integrating the new TinyMCE 4. The development of the native MediaWiki editor is progressing (see current testing page), but not as fast as we expected. In direct comparison, the current BlueSpice solution is still several steps ahead. Due to this, an upgrade of TinyMCE is worthwhile. Changing to the MediaWiki editor remains on the agenda for some time in the future. This could take place at the end of 2014.
  • The dialogue technology is also being upgraded, and we are using the opportunity to improve usability in a number of ways. Users should be able to search for categories and users much faster in dialogues. Long scrolling will become unnecessary.
  • The upgrade of the search function to a new Solr server provides new possibilities: You can now navigate with the search. Many of you will like the new feature “More like this”, which shows similar articles at the bottom of a page.
  • There are also two more tools which will make working with articles easier: From now on, user can create checklists and multiupload enables you to upload several files at the same time. With the new version of InsertMagic, inserting tags and variables will become much easier.

 

3. Less time spent on administration and rights management

There is good news for sysops. Administrators and installers will be able to configure BlueSpice 2 more quickly:

  • The rights management of MediaWiki has “grown” and recognizes a lot more characteristics. We have found a way to make the managing the wiki more transparent for administrators who do not have extensive knowledge of MediaWiki. We are integrating this in BlueSpice 2.
  • If you install BlueSpice 2 for the first time, it will already have the most popular preferences set as default.

 

4. BlueSpice becomes a “real” MediaWiki extension

The major changes to BlueSpice are taking place under the bonnet. BlueSpice has worked with its own libraries for a long time. We did this to keep legal opportunities open for proprietary components. However, something has changed in the general legal concept, so we can do without this special architectural arrangement. And we gain a lot:

  • The systems performance improves, because we can now use the MediaWiki-ResourceLoader – and therefore important MediaWiki resources.
  • The free version, with its new architecture, can now become part of the MediaWiki Git Repository. This is an important step towards developing an independent developer community. You can already catch a glimpse of the initial code version, which will soon be updated on a weekly basis, here.
  • BlueSpice is also becoming more international. Opening BlueSpice up for freelance developers in the global MediaWiki community lays the foundation for many new language versions.

 

5. New themes and user-friendliness

There is also more openness in the new layout and design. The distinctive BlueSpice skin has won many admirers. However, after nearly four years BlueSpice needs a new face. Or to be more precise: It will be possible to give BlueSpice a range of faces.

  • So, BlueSpice 2 comes with a new standard skin. This skin (we have not yet decided on a name) has a responsive design, optimized for mobile equipment. Above all, the range of functions has been tidied up leaving more space for the content. An initial sketch of the new skin will be ready for viewing soon on BlueForge. However, of course, BlueSpice 2 supports the existing BlueSpice skin too.
  • The function Flexiskin gives you more individuality, allowing the basic layout to be customized more easily. Our age old software HalloWiki had a Flexiskin module. Now BlueSpice is getting one too.

BlueSpice 2 aims to provide new momentum and ideas. In any case, we are bringing many important stimuli for the user. And, of course, there is still a long wish list for further features. We will be able to say more about these points at the start of next year. This is when the roadmap for BlueSpice 2 will be updated.

Roadmap: Ideas for the New Version!

A little over two years ago we published the first BlueSpice version. Since that time the software was enhanced enormously. BlueSpice is used in more than 100 countries and the downloads still rise.

No reason for us to pause. This year we will take the software to a higher level. BlueSpice will better cooperate with MediaWiki and will support more languages.

But what else should be done? Which features are missing, how can we optimize the existent ones? Should we focus on improvements the usability or do we need better team management tools?

Join the discussion!

Until July 14th, 2013 we collect and discuss proposals of community members like you at the BlueSpice Feature Poll. The most important and highest rated ideas will likely be included in the next version.

We need your help. Share your ideas with us!

PDF Export for MediaWiki

PDF ExportThere are lots of possibilities for exporting MediaWiki articles as PDF documents.
Some further developments I want to outline here:

Wiki as the central source of knowledge

There are many good reasons for supplying a Wiki with a PDF export facility:

  • Extracts, logs, check lists or short descriptions may be needed on paper or may need to be sent via e-mail.
  • Whole topics or areas of knowledge may need to be made into brochures or books so they can be available, for example, on the website for users, service providers and partners, or offline for field staff.
  • Intermediary versions of handbooks might need to be kept, for example, to supplement contracts and invitations to tender or as documents giving a basis for auditing.

Using a wiki as a central medium here has the obvious advantage that rather than having innumerable PDF documents flying around, the texts can be developed in the wiki and kept up to date. The PDF export function will then give out the most up to date version.

How to create my first PDF export

If you want to add a PDF export facility to a wiki, first work out whether you just want the readers to be able to export individual articles as PDFs or if you want to give them the opportunity to put together a selection of articles in a “book”. The second option is a more technologically complex.

Furthermore, decide whether the firm’s CI should be used and how far you want to go with providing the user templates. Will the PDFs always have the same layout? Do they have, for example, the same coversheet? As soon as this is decided you can get started.

MediaWiki has no PDF export facility in the standard software. However, you can find a whole set of PDF extensions at MediaWiki.org with individual installation instructions:

Pdf Export

  • This extension is being actively developed further and is compatible with MediaWiki versions up to 1.19.
  • It supports a multitude of converter backends (mPDF, MwLib, DOMPdf, Prince). However, non of the backends allows the use of a range of templates. Pdf Export’s templates are encoded tightly in the extension itself. And generally the wiki’s own CSS is used for this.
  • Another shortcoming, in terms of professional use, is that one cannot embed files using Pdf Export. Attached files (Excel, Word, PDF etc.) which are linked to on the wiki are not exported with Export.

PdfBook

  • This extension generates whole PDF books on the basis of categories. This means that you can export several different pages that share the same category. Exporting individual pages is, on the other hand, not possible. Except if you assign a category to just a single page.
  • The extension is kept very simple and so it also has no templates.
  • PdfBook uses HtmlDOC as its converter backend, which is not available on shared hosts.

PDF Writer

  • This extension is just a converter backend for the “Collection” extension and is not usable on its own. There is more on Collections coming up in the next chapter on Wikipedia.
  • MwLib is used as converter backend.

Mpdf

  • Mpdf is a very simple extension which adds an “action” onto the Wiki for exporting a PDF.
  • The extension has little functionality and no support for templates or files.
  • It uses the converter backend mPDF.

Another interesting extension is PdfHandler. This does not produce any PDFs but it does allow one to view PDFs which have been uploaded.

As you can see, the MediaWiki extensions for exporting into PDF we have named above are very useful and helpful, but are generally missing functions which would be useful for business purposes.

On top of this, you have the usual problem with free software projects: Like all MediaWiki extensions, they are provided by independent developers. Thus it is not guaranteed that the extensions is maintained. So it is not always clear if the extension works with the newest version of MediaWiki or if it will ever be updated. And some extensions are constantly in the beta stage of development. For small wiki projects this may not be a problem. However it is rather different when a company is relying on the function, for example for the organisation’s handbook.

What does Wikipedia use?

On Wikipedia and its sister projects Wikisource and Wikibooks, one can bring together arbitrary collections of articles to make a book. In order to do this, one chooses the link “Create a book” under the menu “Print/export” and then one can add wiki articles to the book individually.

In principle, one can also equip any other MediaWiki with the same mechanism as Wikipedia. For this, one needs the extension Collections amongst other things. This is responsible for collecting articles. Collections is a lovely solution which alongside PDF, can also export in the ODF and DocBook XML formats. For this, collections uses the PDF Writer, OpenDocument Export and XML Bridge extensions.

Collections also makes it possible to send contents to a Print on Demand service which then makes professionally printed books. The Mainz company PediaPress GmbH is currently operating this service. Additionally, there is a nice side-effect: The existence of PediaPress ensures that the extensions in and around Collections are regularly updated.

However, using the Wikipedia mechanism is not always ideal for organisations and businesses:

  • The possibilities for adapting the layout are limited.
  • As Collections uses components in Python, knowledge of this programming language is necessary.
  • Attached files are also not supported.

BlueSpice free – PDF export suitable for businesses

For these reasons, we have developed an alternative for the MediaWiki enterprise distribution BlueSpice. The basic idea is summarised by Robert Vogel thus:

Individual pages are exported, and these can be supplied with a template by people with a little technical knowledge, so that the user can print a PDF document with the design of the business or organisation. We employ widely used web standards which many developers are familiar with. This makes individual solutions possible. Instead of Python, we use Java. And BlueSpice’s template system is based on HTML. In this way, templates can be made which have ones own graphics (logos, banners), individual document structure (headers and footers, integration of metadata such as author, date or category) and designs (colours, fonts).

In general, everyone who extends their MediaWiki with the free and publicly available extension BlueSpice has access to this PDF export facility. The free version lets one export individual pages. In addition, the free version offers:

  • The template system based on web standards. This means that with the right technical knowledge, one can write ones own templates.
  • The ability to export special pages, category pages and image pages.
  • The possibility to hide text elements for passages which are not for all eyes.

You can download BlueSpice free and find installation instructions here.

BlueSpice [bookmaker] – A professional module for PDF books

BlueSpice: Adjust your PDF book via the right mouse button

BlueSpice-Paket [bookmaker] equips BlueSpice PDF Export with a book function, subject to a charge.

BlueSpice makes it possible to create books with titles and subtitles using a mask, and additionally to change existing books. The structure of the chapters can be created from scratch or adapted from an existing version, all via Drag & Drop.

To create a PDF book with [bookmaker], it is only necessary to choose the items wanted (if only parts from the book are needed) and click once on the button “Create PDF”. One gets a PDF book straight away.

The PDF is created with title page, contents, release notes and attached files.

If the CSS has been adapted for the firm, then the book gets wiki pages and a title page in the firms design, a clickable contents page, notes on attached files and release notes.

Let us mention two more special features:

  • Including file attachments: [bookmaker] pulls the linked documents (forms, Excel files, Power Point presentations…) into the document and lists them as appendices.
  • Exporting with differing templates: It is even possible to tag a page to use a special template for export.

Bookmaker 2013

BlueSpice [bookmaker] allows the integration of chapter navigation.

We are currently working on further improvements which will become available at the start of 2013:

  • Working with wide tables: Wide tables can be flagged. This means they will be turned on their side when exported. This function already exists in a beta version. However, we want to work with this a bit more.
  • Internal links: Up to now, you have been able to jump from the contents page to the page you want in the document. Internal links in the body of the document still point outside the PDF to the wiki pages. In the future, one will be able to jump to the right place in the document with the internal links.
  • Linking of attached files: Attached files which are linked in the body of the document will soon be able accessible using the links. Up to now, the links have pointed back out of the PDF to the source in the wiki.

The development team is always eager to hear further suggestions.

MediaWiki vs. Confluence? Not a question of features

When businesses want to make use of professional wiki software, they come quickly to the question of whether they should choose MediaWiki or Confluence. Confluence is a wiki specially developed for the needs of businesses. The concept for MediaWiki is, on the other hand, for the huge online encyclopaedia Wikipedia. Having more than 750,000 downloads per year, MediaWiki has a decisive lead as the standard wiki software, in business too.

Fans of Confluence used to complain that MediaWiki was not really suitable for businesses. And one can find serious comparative studies which completely ignore the possibility to extend and adapt MediaWiki. However, the extendibility and adaptability of MediaWiki is an essential feature of the software. The project page MediaWiki.org alone lists more than 1,800 extensions.
And, since the publication of BlueSpice, there is a completely free enterprise distribution for commercial users, which can be extended to suit individual needs via modules.

To show how MediaWiki really is a solution for business, I have collected together the most common objections to MediaWiki and I comment on them below. Continue Reading

Download the BlueSpice Mobile App

Central topics in webdevelopment are cloud and mobile services. The BlueSpice team develops for both new attractions.

Today we reached a new milestone by publishig the first free mobile app für BlueSpice. Now you can view, edit and manage your BlueSpice MediaWiki enterprise distribution from your mobile device (Android or webOS).

Just download the app and install it on your mobile device.

With some reservations this app can be used for MediaWikis 1.15 or higher. But images are not available and the wiki needs an authentication.

We are happy about all ideas for the further develpoment in the project forum. Have a nice time!

Bugfix Release 1.1.1

Some inconvient bugs have been fixed by the BlueSpice developers in the last days. And so we decided to publish a new release of BlueSpice free: Download.

  • InsertCategory shows correct hierarchy
  • InsertFile / InsertLink double button problem solved
  • VisualEditor Word import without <span> and <div> tags
  • ExtendedSearch offers better results
  • UniversalExport / UEModulePDF some bugs (file names with special characters) solved