The idea is to continue the work on XWiki Authenticator and contacts started during GSOC 2016.

The main use case is to get all the contacts of your organization's intranet automatically synchronized on your phone so that you don't have to use a browser, go to your intranet, login and search form some user to see if he entered his phone in his profile. The other important part is to make sure this is as integrated and as standard as possible from Android point of view and allow other applications to use registered XWiki authenticators to access an XWiki instance without the need for the user to give the password to that application.

Current code: https://github.com/xwiki-contrib/android-authenticator
Known bugs/improvements: http://jira.xwiki.org/browse/ANDAUTH
Documentation: http://extensions.xwiki.org/xwiki/bin/view/Extension/Android+authenticator/
 

The first requirements for this project during this GSOC are:

• get something stable enough to release a 1.0 version, especially a good support of bad network
• a nicer and more polished configuration UI

Then any improvement idea is welcome. You can find some ideas already listed on jira and here are a few others:

• add a support for new OpenId Connect Provider for a safer authenticator (no need to store the login/password on the phone)

Filter Stream framework allows converting from one wiki representation to another. The idea here is to provide a Filter input module for DokuWiki so that it's possible to convert from DokuWiki to any Filter output format.

You can get inspiration from http://extensions.xwiki.org/xwiki/bin/view/Extension/Import+DokuWiki+into+XWiki+Application and http://extensions.xwiki.org/xwiki/bin/view/Extension/Dokuwiki+To+XWiki2+Extension.

XWiki 4.4 introduce new translation macro which will allow to find easily translated content in a page when using annotated HTML5 renderer (you can see the result by adding ?outputSyntax=annotatedhtml in the URL).

The idea is to use that and provide a "translation mode" where you can directly select and translate what you see in the page (when the translation macro is used). The idea is also to make easy to contribute to http://l10n.xwiki.org from your local wiki by sending your corrections to it.

Various ideas for the look and feel of this feature:

• https://pontoon.mozilla.org is very nice
• http://direct.hoplahup.net/tmp/Drupal-translation-ODS.png

Right now XWiki Extension Manager support plain Maven and XWiki Extension (http://extensions.xwiki.org) repositories.

The idea is to add support for as much other kind of repositories as possible.

Here are some good examples:

• Nexus
• Bintray
• Pypi

See http://dev.xwiki.org/xwiki/bin/view/Design/ExtensionManagerRepositories for more details.

XWiki community maintain a wiki with a special application to help translation XWiki projects on. See http://l10n.xwiki.org. Sources can be found on https://github.com/xwiki-contrib/application-l10n (but not that it's a bit older than http://l10n.xwiki.org/ which is usually modified directly in pratice).

The goal of this GSOC is to improve it. The student will have to study it and propose improvements, there is no definite list of things to do.

Various ideas:

• make all this a lot more dynamic
  • importing is a long task and you always get a timeout before it's finished (it's still continuing on the server so it's not broken but still). A progress bar could be nice (could be based on Job Module)
  • default translation edition table is not exactly the nicest UI you could think of (http://l10n.xwiki.org/xwiki/bin/view/XE/XWikiCoreResources?action=viewall&language=fr)
• provide tools to refactor things a bit:
  • it's hard to move some translation from one space to another (for example the applicationresources on XE should be on Platform)
• use new nested spaces to better organize resources (the whole platform is in the same space right now for example)

etc.

Develop a Glossary Application in XWiki.

The idea would be to present a list of definitions in the Glossary App (one page per definition), letting users create new Glossary items. This should be developed with the App Within Minutes application.

Then we have 2 possibilities:

• Writing a Rendering Transformation to automatically create links to the Glossary item page when a page renders.
• Provide a Macro so that users can insert manually to both link to a Glossary item page and if this page doesn't exist to directly bring the user clicking it to a new page for creating that Glossary item

Of course there are plenty of other features that can be imagined and it's left to the student to make the best possible Glossary app in the allocated time!

The idea is to be able to integrate RedPen inside XWiki. RedPen is checkstyle for documentation. See this presentation to know more about it.

There are several integrations possible with XWiki that we could imagine:

• As an XWiki extension that can be installed in an XWiki instance and that would validate the content written when pressing the "save" button, allowing the reader to review the errors and either confirm the save or go back to editing and fixing the problems.
• As an XWiki extension that can be executed inside the wiki to validate several pages (this should be done in a Job with a progress bar)
• As a plugin inside RedPen to support the XWiki Syntax. This could be mandatory required for the previous 2 integrations since pages are saved in Wiki format (when you press save in the WYSIWYG editor the content is transformed to wiki syntax). However we could also imagine that the RedPen integration would take the page content and render it using the plain text renderer and then execute the check on that content too.

An even better integration would be the ability to run RedPen on the fly as user types content but I don't know if RedPen allows for this.

The project is to create an authoring tool to create an ebook that works on mobile devices: Android, iOS or any other. The objective is to export spaces of wiki pages within an ePub book (a zip of XHTML files) that can be read comfortably on mobile devices, with or without internet access.

The software should complement the XWiki collaborative editing mechanism to support the author in previewing and verifying the display of the content on various devices (e.g. warning that a given tag is not going to work on the profile Aldiko on Android XVGA, or presenting on a window of classical device sizes to insure a reasonable layout is achieved). It should also apply media-conversion, e.g. scale image or adjust videos to ensure an embedding that is reasonable in size and that works on the target sizes and platforms.

A very successful contribution should, with a small amount of changes, allow developers to also export to other package formats such as Mobi, SCORM or Common Cartridge and maybe even deliver Android's APK applications, integrating Cordova on the server.

Discussion: is to happen on the xwiki-devs mailing-list as well as on the #xwiki IRC channels.

Delivery: open-source code (LGPL) using XWiki, Groovy, Velocity.

As with any other search tool, XWiki's search experience is dependent on the data it searches. Should matches in the title of an attachments be prioritized compared to section titles of pages? Should a particular language transformation be desired?

The tool to be designed is an exploration tool to answer these questions based on the data.

Typically it would allow experts in the domain to see search results and report on them giving feedback on the validity of the results. For example, this tool would calculate precision and recall based on the feedback.

It would also include a method for the search tool manager to see the explanation of a search result so as to understand why a given score has been given.

Finally, the tool would come with a workflow explaining how a search tool can be evaluated and adjusted, in the form of a video and a text tutorial.