Browse Tag by MediaWiki

Advent calendar 14: Describing code syntax in the wiki

14-Advent-Calendar-Nowiki
A wiki is a place for documentation in general, but sometimes it is also used to describe how to use the wiki itself. For this reason – and also for other computer code-related descriptions – you will need to display code snippets to explain how something works. But how to do this without getting an error of the wiki syntax? Especially if you want to give an example for wiki code – it won´t work, because the wiki interprets it as a functionality, link or markup.
There is a very simple trick: just let the wiki know, that the next characters are no wiki code. You can do this with the <nowiki>-tag. Here is an example:

<nowiki><bs:countcharacters></nowiki>
or
<nowiki>[[Special:Version]]</nowiki>

The wiki won´t show the number of characters or set the link to the special page, it will just display the text between the tags in your article.

Especially for computer code, there is an additional <code>-tag. This formats the text with a light grey background and another font to highlight a code snippet. Combine the two tags to display code in an article, e.g.

<code><nowiki><bs:countcharacters></nowiki></code>

 

Advent calendar 9: Use the spell checker in BlueSpice

9-Advent-Calendar-Spellchecker

The functionality to use the spell checker of your browser, is already included in BlueSpice free. What you need is to install the appropriate dictionary for the language you want in your browser. Those are available as addons. After you installed the dictionaries, you only need to activate the spell checker in the editing mode of your wiki article. Just open the menue of the spell checker with a simple command:

Firefox: Shift+right click
Chrome: Ctrl+right click

In this menue, you can activate or deactivate the spell checker, choose the languages and get suggestions for words.

Advent calendar 5: Hide the table of content

5-Advent-Calendar-Hide-table-of-content

If there are more than two headings, the wiki will automatically show a table of content at the beginning of an article.  You don’t want the system to display this index?

Then put __NOTOC__ at the beginning or end of the article in the wiki code and there won’t be a table of content anymore.

Advent calendar 4: Display a RSS feed in a wiki article

3-Advent-Calendar-Import-RSS

If you want to keep your users up-to-date and provide them the latest news and information from an external site, the RSS feed is the media of your choice. And you can also use this great functionality to display the news in your wiki. Just get the URL from the RSS feed from the website you want to import. In our example, we took the RSS feed from our BlueSpice blog. And here comes the example:

<rss max=4 highlight=”MediaWiki BlueSpice”>https://sandbox.kulturbanause.de/old-blog-bluespice/feed/</rss>

Put the URL between the rss-tags. Additional variables can be used, to configure the output on the page. “max 4” means, that only the last four news will be displayed and “highlight=”MediaWiki BlueSpice” marks the words “MediaWiki” and “BlueSpice” wherever they appear in the text. This is how our example looks like in the article:

 

RSS Import in BlueSpice
RSS Import in BlueSpice

There are more variables to configure the output. Find out more in our helpdesk article about the RSS import: https://help.bluespice.com/index.php/RSS_Import

And there is also an extra portlet in your dashboard, where you can display the RSS feed, too. Open your user dashboard and add the “RSS-Feed” portlet. All you need to do now is to click on the cog wheel icon and insert the URL in the dialogue. Save it and get the latest news!

View Post

Advent calendar 3: Changing a page title without moving the page

3-Advent-Calendar-Displaytitle

 

Sometimes it can be useful to change the title of a wiki article, but without moving the page. This means, that the URL stays the same and all links that refer to this site remain active. Only the title in the content will be displayed differently.
For example: You created the page “Prices” as a subpage of “Products”. The title will be shown this way “Products/Prices”. You don´t like it, because you only want “Prices” to be shown as the page title? Just use the variable  DISPLAYTITLE  to define any title, which should be displayed. Here is the code, according to our example:
{{DISPLAYTITLE:Prices}}

There are lots of use cases for this feature, e.g. if you want to shorten a very long title, if you want to hide the prefix of a namespace (like turning “Portal:Quality Management” into “Quality Management”), and so on. Or also if you want to overcome the MediaWiki obstacle of the mandatory capital letter (for example an article about the “IPod” looks much better if you change it to “iPod”).

Attention: Please take into consideration, that it could confuse your users when they are looking for the article. They keep the title in mind, but can´t find it because the wiki system is still using the real title of the page.

 

 

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

Continue Reading

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.

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). Continue Reading

BlueSpice and MediaWiki templates for content boxes

With this wiki box set, it is possible to achieve more structure and overview in a wiki article. You can highlight content and distinguish it from the surrounding text. These boxes are a great support to improve the quality of an article and to add some design to the articles to make it more appealing for your interested users. You can insert text, links, files and lists into the box – the same way like you know it from normal wiki content – to provide useful tips, documents and further information in addition to the article text. Use this content highlight boxes in MediaWiki or in BlueSpice wikis – it is compatible with both systems.

You can buy them in the BlueSpice shop : you will get eight designed content boxes as easy-to-import xml-files, with extra designed icons, a usage description and master copies – for only 7,99 €. We provide the box templates in seven different colors: green, grey, orange, purple, red, turquoise and BlueSpice style (CI). The colors of the box set perfectly match with the navigation icon sets, which can be downloaded for free in the shop. The boxes are responsive and available in English and German.

Box Documents: Link important documents, that are related to or necessary for the article. In the box, readers will notice immediately.

box-Documents-bluespice

Box Good to know: Write a short hint and make it more visible with the “Good to know” box.

box-Good to know-bluespice

Box Info: Set a highlight of an important abstract or a accentuate a note with the “infobox”.

box-Info-bluespice

Box News: Separate news or updates from the rest of the article.

box-News-bluespice

Box Protocol: Link related protocols so that they get the attention they need.

box-Protocol-bluespice

Box Related Articles: Link similar articles manually to connect related articles and motivate the user to read more about this topic.

box-related articles-bluespiceBox Tip: Insert some helpful information in the “tip” box – readers will be thankful when they don’t have to search for additional advices.

box-tip-bluespice

Box Useful Help Articles: Link – for example – to the BlueSpice helpdesk, to YouTube tutorials or to helpful documents in your file system.

box-useful help articles-bluespice

 

Knowledge management and handbooks in the financial sector: A wiki with blog for the Saalfeld-Rudolstadt district savings bank

“Finally, more time for business thanks to the Web 2.0 – The Saalfeld district savings bank cracks open its knowledge silos and finds a new way to deal with rules” by Christian Sauer (summary of the progress report by Nathalie Köpff).

It is well-known that many things in Germany are over-regulated. Instead of supporting creativity and entrepreneurial thinking and action, too much regulation blocks the big picture and leads to redundancy, or in extreme cases to contradiction. The introduction of the Web 2.0 breaks open knowledge silos, helps colleagues share newly-acquired knowledge, in a central place accessible by all, for example in the intranet. Members of staff should have an information platform available which motivates their active cooperation, adding discernible value.

Online organisation handbook and open documentation

The Saalfeld-Rudolstadt district savings bank wiki meets both requirements. One part of the wiki satisfies the statutory and supervisory editorial requirements. This area fixes the procedural rules for business operations. Amongst other things, there is an open area in which the staff can freely document their knowledge. A blog provides support for the system, giving a non-binding form of transmitting information.

The main page of S-Pedia links to important innovations
The main page of S-Pedia links to important innovations

The backing of the management was indispensable to guarantee a wide enough basis for support and initiative. Furthermore, users were needed who really see the need, and last but not least a suitable provider. To get the project of the ground, one has to concentrate on the users, as they will be working with the system later on. For this reason, members of staff from the most diverse divisions of the company were integrated into the planning process right from the start. Taking the requirements of the users into account early on, avoids acceptance problems later on and developments missing the users’ requirements. In the case of the district savings bank, the first job was to determine the central activities clearly and specify a name for the platform: S-Pedia. Continue Reading