Hi everyone,
We’re getting close to a new XWiki cycle: XWiki 11.x.
We’re curious to hear from XWiki users what they’d like to see and what they think we should focus on. No promises but we’ll listen 
I’ll also post later some ideas that we have.
Thanks. Let’s start!
PS: For reference, the thread from last year about the 10.x cycle: XWiki 10.x cycle roadmap
Here’s a thread we need to review to see what’s been done/what’s left:
We, AutomationX, are using XWiki as an Intranet interally (meeting protocols, blog post news, internal information) as well as a knowledgebase / software documentation plattform for our products for both, external customers as well as our co-workers who use the software.
The following is a work in progess brainstorming
You are already working on this This means enabling WYSIWYG experience for most daily tasks (autocompletion of stuff like links etc. etc.) which has greatly improved recently. Time has shown us that most of the users are in no way willing to learn xwiki syntax or anything in that direction, everything has to be a kidsfriendly-applike-facebook-instagram difficulty 
The following to things are the only BIG issues we face, which are still unresolved in XWiki 10.10 for us.
Our customers often demand “offline documentation”, like something they can print out (for real)
Issues (1) und (2) are somewhat mitigated by the greatly improved HTML Export, so maybe we should scrap PDF and focus on HTML completely (they can carry it on USB and save some trees)
If you export the Sandbox Page to PDF in latest xwiki 10.10, it looses lots of formatting. I don’t know if this is a limitation of PDF / OpenOffice? If I copy paste it from Firefox to M$ Word 2013, it has some of the same issues. Exporting has improved a lot since xwiki 8.4.3 though
{{code}} Macro Syntaxhighlight does not use monspaced font in PDFIs openoffice used for the pdf export? I had noticed Libre Office does a better job on importing office. Since the docker images contains openoffice, I haven’t used libre office in a while.
The was the greatest loss when we ditched mediawiki, since that had the export to book feature, which rendered a really nice pdf for several pages.
As far as I can tell, none of the available PDF export solutions for xwiki work satisfactory.
Maybe there is some browser extension which could help us.
Does the job and is easy to use, but if you export multiple (child-)pages, everything is crammed together:
org.xwiki.rendering.macro.MacroExecutionException: Failed to evaluate Velocity Macro for content
HTML Export of spaces is pretty great! It looks exactly like the live version, and retains relative page links so you can user links to navigate between offline documents.
We heavily rely on the {{children}} Macro for navigation, since manual hyperlinks are time-consuming. These are not rendered in HTML export, in contrast to e.g. the {{toc/}} macro.
It would be great to optionally execute all macro content during HTML export, and save the macro output in the export. This would be sufficient for our cases I guess.
The same goes for the Navigation Panel and Breadcrumb dropdown menu, but this is lower priority.
In offline HTML the following elements should be excludeable / customizeable , to show only Pagecontent in the export:
We are currently writing all our content in German. Manually maintaining everything also in English is unmanageable for us. We use a custom Panel with a google translate widget, which works fine for viewing single pages.
But this is not usable when using PDF (1 & 2) or HTML (3) Offline Export. I’m not aware of any xwiki extension aiding in that. Maybe there is some browser extension which could help us.
[EDIT]: to clearify, the task is to either:
a) automatically translate content of several pages to english in the course of exporting them to PDF or HTML, which would have to be done on the server side.
b) Translate complete spaces of xwiki pages in a batch job and store the results in english translations of these pages. THEN export the pages to PDF or HTML using the English content.
Other points:
This extension is great! In my opinion the best one to easily improve content navigation and visualisation. Tags are too easly overlooked and are meant for a different purpose.
Repeatedly some of our users complain about the search function. Most of the time it is PEBKAC , like not using a * wildcard or using wrong key words in general. I haven’t deep dived into Apache SOLR configuration yet.
Maybe there can something be done to make search more “Google like” ?
ServiceAccess does not match Pagename ServiceAccessMethodBenutzer Verwaltung does not match Pagename BenutzerverwaltungSome users still want to actually print out pages. If you Print a xwiki page (to pdf or to paper), the layout contains some ugly elements, which are mostly undesired IMHO (could depend on user needs).
The printed layout looks better then the current Export to pdf result.
The default layout could be improved by the following points. Typically, the users wants to print CONTENT, and content only.
Example is XWiki Sandbox Page, PDF via Foxit PDF Printer:
Page Titel is an the far top left side, und therefore cut off on some printers, this should be centered (?) in the header
Top right side shows ugly url
and 4.) All hyperlinks are rendered twice (probably intentional), label and url. If you have a deep hierarchy, the breadcrumbs can get huge, see following screenshot:
The page bottom shows TAGs and Comments, even if there are none. Show tags only if they exist, hide page comments by default.
For the time being, thanks a lot.
BR Mario
Depends on the browser. I know you have that out of the box in Chrome (my parents use that a lot) and I’m sure an extension exist for Firefox and other browsers too.
Regarding which topic, content translation or PDF-book-generation of mulitple pages?
The crucial point is that our customers don’t have internet connection on some plants.
I agree about the items you listed in this category and I think it’s relatively easy to do. That would be good things to improve. Now I’m happy that you’re valuing the HTML export because it’s not a feature I’ve seen used a lot so far (which explains why we’re lacking those features).
I find the use case of offline interesting. I hadn’t thought much about it as a use case for HTML export but it does make sense, and it’s much simpler to get it perfect than to get PDF export perfect.
The docker image actually uses LibreOffice: xwiki-docker/template/Dockerfile at master · xwiki/xwiki-docker · GitHub
Actually I read it too quickly. I tough you were talking about auto translation of HTML content in the browser but seems you were talking about translating the content while doing the PDF export and indeed it won’t help for this use case since it’s done on server side.
No it’s not. We use the architecture described in the diagram at https://www.xwiki.org/xwiki/bin/view/Documentation/AdminGuide/Configuration/#HCustomizingthePDFexportLook26Feel (Apache FOP/XSLFO).
I don’t recall if we tried to use OO/LO to perform the PDF export and what result we got. We do use OO/LO to perform RTF exports for example. Maybe @mflorea or @tmortagne remember?
It’s true that we haven’t worked on the PDF multipage export over the years and it’s the last type of exports that doesn’t not support multipage export. There used to be https://extensions.xwiki.org/xwiki/bin/view/Extension/PDF%20Export%20Collection%20Application meant for that but it’s an extension and it’s not been supported by the XWiki dev team and has probably decayed over the years (i.e. not been maintained). It might not be hard to make it work again though.
For reference @evalica has done some design pages with ideas a long time ago:
There were also some design pages by others:
This is not easy since the trees are dynamically loaded (and doing this in JS, i.e. client side). So we would need to replace them by some static list fallbacks containing only what’s displayed on the screen for example. But then they are not going to be useful in the majority of cases… But better than displaying something empty for sure 
I’m not sure what you’re proposing here. To have some sort of auto translation help (using some external api like google translate) to automatically provide a translation when editing a page into a language that doesn’t have any content?
You mentioned something about PDF/HTML export but I didn’t get it. Do you mean choosing the language of the pages to export or something else?
Thx
My guess is other xwiki users have already developed their own solutions or use some tool. Even some of our guys mentioned he had some tool lying around that crawls a target page to some depth and downlaods everything into files.
Or everybody is always online nowadays 
but that can’t be the case in let’s say an nuclear power plant (exaggerated)
I agree, this is asked very regularly. We do have some guide to explain how you can configure this I believe. I couldn’t find it on https://extensions.xwiki.org/xwiki/bin/view/Extension/Solr%20Search%20Application though, weird. @mflorea any idea where it could be? Thx
@tmortagne got it right:
So all our content is in e.g. German. There is no English “Translation” stored within the xwiki pages.
We’d like to export a space to PDF or HTML and have the results in English.
I will update my original post to clearify.
Since Google Translate and so forth run client-side and the export on the xwiki server, thats a challenge.
Another possible approach would involve two steps:
Use some tool to read all xwiki content pages (german), translate it to english using some translation service, and save the results to the corresponding xwiki pages, as English Translation.
This would have the additional benefit of having english content without always live translating. Since the XWiki UI langage and the page content language are still one, english customers (english browser) would then have an english interface.
This translation batch job could run once every month or once every quarter year.
Then Export all content to PDF or HTML using the english content version, which is now available server side since it resides in the sql database.
WDYT?
PS: I just googled keywords like “web crawler” and “website downloader” and there is an vast amount of free software availble, maybe something is suitable.
There are probably some more urgent ones. Note that I’ve listed only very urgent things (I didn’t list stuff like Rendering 3.0, “new” Model, etc). Feel free to add more urgent ones.
Added the following in my original post above. I dunno if nobody prints anymore today 
Thx. For this I suggest you create JIRA issues fi they don’t already exist.
I would add “Upgrade to jQuery 3.x” to “Urgent technical challenges for 11.x”.
Other technical stuff:
<version> to not mess with master and be careful about security regarding stuff injected trough a pull request)