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
• https://wiki.jenkins.io/display/JENKINS/Translation+Assistance+Plugin

Location where to code this: https://github.com/xwiki-contrib/application-translation

A project already exist to help migrate from Confluence to XWiki: Confluence.

It's already very useful but there it could be improved in various ways. You can find a lot of ideas in Jira but here are big ones:

• fix various remaining bugs
• add support for many more standard Confluence macros (see Anchor macro for inspiration)
• Confluence REST API based input: the idea is explore the possibility to get data from a running instance of Confluence instead of the current database export

The idea is to build a bridge authenticator around PAC4J. XWiki allows writing custom authenticator and there is many of those, see http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/#HCustomAuthentication but they are written one by one and they don't share much with each other.

It would be nice to have the possibility to reuse the tons of authenticators that comes with PAC4J. Doing that means doing some plumbing and wiring to transmit all the information required by PAC4J and back to the XWiki authentication API (and UI when required).

It's possible to use XWiki as OpenId Connect provider and also make XWiki authenticate on OpenId Connect provider. See OpenId Connect project page.

It work well but has various limitation that it would be nice to fix. You can find various ideas on Jira but here are the main ones:

• both
  • setup integration tests
• provider:
  • UI to manage authorizations
  • salt the stored token
  • allow accessing any resource using access token
  • add support for registering clients (only allow a set a clients with generated authorization key) and provide corresponding UI to manage them
  • improve the UI (very basic right now)
• authenticator:
  • support automatically authenticating a user who is coming back

Currently, the PDF export of XWiki is implemented based on XSL-FO and transformation of XHTML to FO. This poses a couple of problems, mainly related to the current level of support of FO from libraries implementing FO to PDF transformation, as well as the limitations of automatized transformation of XHTML to FO. The problems are mainly related to styling limitations, auto-layouting, etc.

The idea is to try to replace this with a pure XHTML & CSS (paged CSS) export, using an open source library for producing PDFs out of this.

This is only the first step of this project, the next steps being to validate that all customisation that is currently possible on the PDF export will remain possible with the new tool, and explore the new capabilities of the export (once ported to the new technology), build tools for it, etc.

See:

• http://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HCustomizingthePDFexportLook26Feel
• https://www.w3.org/TR/css3-page/
• https://github.com/flyingsaucerproject/flyingsaucer (or equivalent tool)
• notable issue https://jira.xwiki.org/browse/XWIKI-5627 (and its related issues)

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 a collection of wiki pages within an ePub book (a zip of XHTML files) that is downloaded. While this seems trivial, the challenge of this project is to make it so that it 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 particular ePub readers, or previewing the rendering so as to verify the layout). It should also apply media-conversion and embedding, e.g. scale images so that it works well 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 Daisy, iBooks or SCORM.

Delivery: new "xwiki extension" project to be created on github with open-source code (LGPL) using XWiki, Groovy (or java), Velocity.

Overview

Documents stored in XWiki can contain structured data, in the form of XObjects. The structure of these XObjects are defined by XClasses, that can also be created in XWiki documents. Learn more about how XWiki manages XClasses and XObjects here.

Most of the application that we create inside XWiki depends on this model, as it is really easy to access and edit (through a simple page edition). However, once a data model (through XClasses) is defined by an application, it is hard to rework it. On the contrary to databases where it is possible to create migration scripts, XWiki does not provide a migration framework in its core.

Technical structure

The goal of this project is to make improvements to an already existing migration framework (see the documentation and the code). The existing framework can be divided in three components :

• The core of the framework : its APIs and its main components
• Migrators : we define a migrator as "something that will execute a migration in the wiki". A migrator could migrate XClasses from one model to another (as explained above), migrate a document content to another document, etc ... the idea is also to help application developers creating their own migrators specific to their use case.
• The development toolkit : a set of scripts and services that can help an XWiki application developer creating new migrations for his application.

Objectives

As part of this project, you will contribute in the following :

• Creating new migrators in the framework itself
• Make sure that migrations can be executed when upgrading an extension
• Improve the development toolkit of the migrator to help application developers create new migrations
• Improve the testing strategy of the whole framework

Requirements

A good knowledge of the Java language is needed along with some experience in development in general. You don't need to fully understand the complete structure of XWiki before starting this project.

Other resources

• Issue tracker : http://jira.xwiki.org/projects/MIGRATOR/issues
• For any question, please feel free to ping @caubin:matrix.org or @aluca:matrix.xwiki.com
  on our chat

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
• Fix all left tasks
• Rewrite most part of application on Kotlin according to Google Android recommendations

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)

We need a tool that supports site administrators to raise the quality of the (Solr-based) search results by performing experiments.

A facet is for users which are invited to use the search tool and provide feedback on the relevance of individual results (relevant/not-relevant/should-be-elsewhere). The tool needs to collect feedback in an effective so it can be used by site administrators.

The other facet is for administrators to explore:

• what is stored in the index for each document (index explorer)
• why a given query yielded a given document and with what score (based on the Solr explain)
• adjustments to the weighting of individual fields (e.g. using the eDisMax query parser)
• how the indexing process (e.g. the language-specific features) transforms and stores pages and documents (combining what Solr and XWiki does)

Search quality evaluation is a traditional field of information retrieval. More can be read about it in the IR Book or in the summary of K Manesh.

Integrate the Mermaid library into XWiki by creating an XWiki Extension for it. Mermaid is useful to create flow charts, sequence diagrams and Gantt timelines.

Goals & Ideas

• Create and release a Contrib Extension for Mermaid
• Offer an XWiki Rendering macro for it, {{mermaid ...}}...{{/mermaid}}
• Make it work in the WYSIWYG editor (i.e. ability to enter text and click on a button to get live rendering - Button displayed inside the Macro viewport, to toggle source and rendered view).
• Integrate it with existing Project Management Extensions so that these projects can offer Gantt diagrams for example.
  • This means ability to generate Mermaid syntax from other sources of data (e.g. from temporal XObject data for the Gantt part)

Related

• PlantUML Integration
• YUML Integration

Right now the LiveTable macro we offer is a Velocity Macro which makes it hard to use for non-technical users. It would be great to have a Rendering Macro for it (i.e. {{livetable ...}}...{{/livetable}}).

Goals & Ideas

• Review how the current Velocity Macro works
• Review the design that was started for a new macro. Also review this existing extension.
• The goal is to provide a generic solution that is both very easy to use for non-technical users for simple tasks and 100% complete to cover all possible use cases for technical users. The goal is to replace all usage of the current #livetable macro in the XWiki code by this new macro.
• Review existing open issues related to the LiveTable to make sure that the new macro can cope with all the use cases
• Implement the new {{livetable ...}}...{{/livetable}} macro, as a Contrib Extension as a first step, and then later on, provide Pull Requests to integrate its usage in the XWiki code base.
• As time permits, work on existing LiveTable issues.

Develop a set of XWiki Rendering Macros to make it easy to perform well-defined tasks in XWiki for non-technical users. Right now everything is possible using the Scripting macros of XWiki. However that's reserved to technical users. The idea is to identify common needs and implement specific macros to fulfil those needs.

Goals & Ideas

• Form macro + Button macros to avoid needing the use of HTML macro and very simply add a button or a form in a wiki page. See also Form in page FAQ
• Search macro to display a Search box in a wiki page and to display search results, with possibility of passing search parameters.
• Members macro to display all the members of a given Group into a LiveTable and/or a Tree
• Contributors macro to display all the authors who have contributed to a wiki page.
• Develop these new macro as XWiki Extensions on XWiki Contrib and release them.
• Propose new macros if time permits it. Ideas can be taken from New macros idea list. Some of these macros have already been implemented but the implementation may not work anymore in the latest versions of XWiki or can be improved. Improving them using new technologies would be great.

Work on several Demo Flavors for XWiki. A Flavor is a set of XWiki Extensions working together to achieve a goal. The idea here is to propose several Demo Flavors for common usages of XWiki in order to show users how XWiki can be used to achieve these usages.

Goals & Ideas

• Identify several commons usages for XWiki. There are already some design pages that exist on this, see Flavor design. The idea is to offer some very specific flavors (not generic flavors) so that the Demo can be specific and directive / self-explanatory
• For example, you could image a Demo flavor for using XWiki for managing a Bike Shop. The idea would be to:
  • Write a small Applications Within Minutes application
  • Provide a simple skin and color theme for the Bike Shop
  • Install some existing Extensions that are useful for the Bike Shop use case, for example the Calendar application to manage deliveries of Bikes, or the Task Manager Application to organize tasks needed to manager the Bike Shop.
  • Write several wiki pages and provide demo content to simulate real content. Also provide content pages to explain how the demo is created using existing XWiki Extensions & technologies
• Write 1 or several small Demo flavors, depending on the size of the flavors chosen and the time available.
• Keep in mind that the goal is to demonstrate XWiki Extensions and Technologies so that users understand that XWiki is not just a wiki and can be used to implement applications.

Related

• Existing Demo Flavor. The idea is that it's too generic and should be replaced by smaller and more focused demos with demo content.

XWiki supports Events for various actions done in the XWiki: creating a new page, modifying a page, doing an action, etc. It's possible to write Event Listeners in Java or in Wiki pages.

However it would be great to be able to register Web Hooks in XWiki so that events would trigger Web Hooks, i.e. call remote APIs to notify them about the event that has just happened.

Goals & Ideas

• Provide something similar to GitLab's System Hooks and Web Hooks.
• Write a generic Event Listener that listens to all events and forward them as remote API calls when events occur.
• Also provide an Admin UI so that users can register URLs for specific events.
• Implement this as a Contrib Extension and release it

The JIRA issue corresponding to this need is XWIKI-16088.

XWiki Standard current provide two different stores for attachments and deleted documents:

• filesystem storage (the default)
• hibernate storage

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Attachments#HAttachmentStorage for more details about the attachment store.

The idea is to add a JCR-based (Java Content Repository) XWiki storage to make possible to plug many possible implementations. Also, with the multiplication of stores, a tool to move data from one store to another would be necessary.

The expected minimum for the project are:

• a generic JCR bridge extension
• an extension pulling the bridge and a well tested implementation of JCR (like Jackrabbit Oak)
• an application to move data from one store to another

Provide an Amazon AMI for XWiki to allow starting XWiki on Amazon EC2 easily.

See also this existing ticket.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kind of usages, and thus increase our Active Installs.

Goal

Provide a packaging/distribution to deploy XWiki on Google App Engine to allow starting XWiki on Google App Engine easily.

The main goal is to offer more ways to distribute XWiki to make it more attractive to all kind of usages, and thus increase our Active Installs.

Related

• See this old thread about XWiki and GAE

The objective of this project would be to integrate powerful Javascript visualization libraries in XWiki and particularly those that would allow editing of the visualization, and extend XWiki internal APIs to make it easier to integrate such libraries.

Examples libraries to integrate:

- mapjs mindmap (includes wysiwyg modifications on a mindmap)
- vis.js timeline & graph (includes wysiwyg modifications on a timeline or graph
- vizjs (graphviz)

In terms of XWiki features that could be integrated in the XWiki core:

- support for a REST api to save the content of a macro being edited
- support to saving an "image" version of the visualization capturing the div including the visualization (which would allow PDF export on the visualization)
- support for realtime rendering of a visualization versus the macro content (change the graphviz content and render it in realtime)

Overview

As a knowledge management software, it is critical for XWiki to help its users to better organize the information that is put on the wiki.
One frequent problem of wikis is that content is being put in wikis but can not be capitalized/used because it's difficult to retrieve once put in the wiki (because not properly organised, or because search engines are not performant enough).
Usually, in all communities that collaborate around creating a knowledge base, there are a few people (the "gardeners") that watch over the good organisation of the wiki, make sure that all content that is being added is not duplicate, that it is put in the proper place on the graph of knowledge, that relations are properly setup with related documents, etc. The purpose of this project is to use all available language processing / artificial intelligence / machine learning tools in order to create replace the gardeners with robots.

Objectives

The main goal of this project is to build a tool to help document editors to better organize their pages and the pages contents. This tool should be a combination of machine learning coupled with natural language processing. The tool should be able to propose different forms of organisation of content to the editors, which editors can apply to their content or not. Ideally, the automatic gardener would learn from the answers of the editors and improve its algorithm.

A few examples of gardening actions:

• detecting duplicate content
• proposing to update a page rather than create a new page
• inferring a structure (in the sense of the wiki's structured pages) from the created content and proposing to add this structure to a set of pages
• proposing a location for a page on the wiki (depending on its content)
• etc. The list is really open, a full analysis of the possible actions should be done by the student.

Requirements

• Good knowledge of machine learning
• Good knowledge of Java
• Basic understanding of knowledge management needs

Other resources

Create a helm Chart for XWiki to seamlessly deploy XWiki to Kubernetes. Official helm charts could be used for Database dependencies. 

• Support for both Ingress Ingress and Istio. 
• Option to choose between using an external database, a single node DB or a multi-cluster DB setup using other official helm charts as dependencies. 
• Should support popular hosted Kubernetes services like GKE and Amazon EKS and Minikube(for local development).

Existing resources:

• https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Installation
• https://github.com/xwiki-contrib/docker-xwiki
• https://blog.zwindler.fr/2017/10/24/tutoriel-xwiki-ma-premier-appli-stateful-sur-kubernetes/ & https://blog.zwindler.fr/2018/02/06/se-simplifier-kubernetes-helm-charts/

DokuWiki importer has seen two iterations in GSOC so far in 2017 2018. There's still room for plenty of improvements. 

• Fix remaining bugs. 
• Understand and document the Macro Framework. 
• Add support for popular DokuWiki plugins using the Macro framework. 
• Add more syntax extensions like Fallback formats

Overview

Renjin is a JVM-based interpreter for the R language. In other means, it allows the execution of R code within the JVM to perform some calucations and statistical operations.

Objectives

This project can be divided into several goals, the first goals represents the key features of the application that would ensure its usability, and the next goals would allow the application to be applied a wider range of use cases.

1. R code macro : create a macro within XWiki allowing to execute R code using the Renjin engine
2. Allow plots generated through a R script to be rendered into a wiki page upon the script execution
3. Create an interactive interpreter within XWiki to use the R command line interface
4. Allow R extensions to be integrated within XWiki either through a specific interface or through the already existing extension manager

Requirements

• Good knowledge of Java and JavaScript
• Some knowledge of the R language

Other resources

• The Renjin website : http://www.renjin.org/

The idea is to develop an importer to import GitHub pages written in GitHub-flavored Markdown into XWiki pages written in XWiki Syntax 2.1.

To do that you would use the following existing modules in XWiki:

• Filter Application. This is a generic framework and UI to convert from one format to another.
  • Filter Module
  • XWiki instance output filter
• You can use examples of existing importers:
  • Confluence Importer
  • MediaWiki Importer
  • DokuWiki Importer
• Markdown Syntax
• Git API

Here's an idea of a possible implementation workflow:

• Since there's no GitHub REST API to access GitHub wiki pages, use the XWiki Git API to checkout/clone the underlying Git repo containing the GitHub wiki pages.
• Write an input Filter that takes as input a Git repo containing GitHub wiki pages. Use the existing XWiki Instance output filter to convert that into wiki pages.
• Use the Markdown Syntax to parse the GitHub pages and use XWiki Rendering APIs to convert that to XWiki Syntax 2.1
• See this snippet to import from GitHub

This project is about the creation of an application that will let users create collaborative maps with XWiki, where each point or area on the map will be associated with structured data.

Typical use cases

• As an employee of a town hall, I can create with my colleagues a map showcasing the main city points of interest: museums, gardens, libraries, swimming pools etc. When clicking on a point of interest, a popup displays information about the place, and gives access to a page containing further information.
• As a professional guide, I can create a path linking various points of interest and display it on the map.
• As an editor, I can choose the user experience from predefined experiences combining media, timelines, paths etc. also known as "story maps".
• As a city planner, I can describe a city planning project with my collaborators, drawing various shapes on the map (polygons, circles, squares, etc.) and associating content with each shape. I can also manage several layers of data and choose which one(s) to display.
• As a user, I can, directly from the map, search across a large number of data elements, by using a contextual search widget that displays the results as a list on top of the map. When selecting one result, the map focuses on its location.
• As a user, I can use the application efficiently from a mobile device.
• As a user, I can be geolocalized and view my current position on the map and I can get instructions on how to get from my current location to a given point of interest on the map (in my preferred language, if possible).
• As an administrator, I can configure the map background: I can choose from existing background configurations, or I can create custom map backgrounds using external services such as Mapbox.
• As an administrator, I can configure external geographical data sources, for instance to display on my map some entries fetched from Wikipedia. 
• As an administrator, I can make the map background available in offline mode (on a specific geographical area), so that it can be embedded in an ePub file.

Notes

• For advanced features such as custom layers and shapes, the application will primarily target the usage of the OpenStreetMap API.

See also

• Existing XWiki map macro
• Leaflet JavaScript library for mobile friendly interactive maps
• Collaborative mapping Wikipedia entry
• MapHub
• Mapbox studio
• GoGoCarto
• Umap
• Humanitarian OpenStreetMap Team
• Example of user experience combining map, search, filters and result list
• MediaWiki maps extension
• Storymap library and examples by Knightlab
• ESRI story maps creator

The idea is to allow browser to autocratically authenticate on XWiki using the new WebAuthn standard.

For more details about WebAuthn see the following links:

• https://webauthn.org/
• https://www.w3.org/TR/webauthn/
• https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API
• https://webauthn.me/

See https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Authentication/ for details about XWiki authentication framework.