Written by
Lorina Balan
, Digital Marketer
On June 24, we hosted our live webinar, “How HLS modernized its content platform with XWiki”.
Attendees joined to see how the Historical Dictionary of Switzerland (HLS) transformed an outdated publishing system into a modern, collaborative platform that supports multiple languages. Neculai Dăscălița from XWiki and Stéphanie Summermatter from HLS shared their experience, from initial challenges to practical lessons you can apply in your own organization.
What we covered
Migrating to XWiki brought real and measurable improvements for HLS:
- Structured editorial and translation workflows: Every article now moves predictably from draft to publication, fully integrated with Jira.
- Multilingual templates: The team manages German, French, Italian, and Romansh content consistently, reducing duplication and improving quality.
- Powerful Solr search: Filters help users quickly find the right information, while clean URLs make navigation simple and boost SEO.
- One-click PDF exports: Editors save time by generating PDFs without manual formatting.
- Fast and intuitive front end: The new interface is distraction-free, enabling users to focus on the content.
- Flexible publishing options: Teams can label updates as major or minor, allowing quick edits without republishing everything.
Lessons learned
#1 Flexible templates make complex publishing manageable
For HLS, structured templates in XWiki were essential to handle multilingual content without duplicating effort. This confirmed that flexibility in content models is critical when teams work across multiple languages and formats.
#2 Clear workflows reduce friction
Integrating Jira with XWiki workflows meant every article had a predictable path from draft to publication. This clarity helped HLS editors track progress and maintain consistency across teams.
#3 Simple design improves usability
A clean front end with intuitive navigation and minimal distractions made it easier for users to find and read content. This reinforced that simple interfaces often work best for large knowledge bases.
#4 Planning ahead supports growth
Adding Romansh as a fourth language partway through the project was smooth because the platform had been designed to scale. Thinking ahead about future needs saved time and rework later.
#5 Training and change management matter as much as software
HLS dedicated time to train their team and adjust processes. This investment made the switch sustainable and reduced resistance to change.
These lessons continue to shape how XWiki supports teams who want to move beyond outdated tools and build content platforms that grow and adapt over time. If you’d like to see how it all came together, you can watch the full webinar recording to hear directly from the HLS team, or explore XWiki yourself to see how it could work for you and your organization.
Questions and answers
Q1. Do the HLS pages meet the WCAG criteria, so can they be considered accessible?
HLS did not run a dedicated WCAG compliance audit. However, the project is built on XWiki, which aims for full WCAG Level AA conformance. In practice, the site’s accessibility matches what XWiki supports out of the box.
Q2. Which system was formerly in use at HLS?
HLS used a custom XML-based editing system developed in the 1990s and updated in the early 2000s. It was mainly designed for print, with online publishing added later.
Q3. Is BFSG (Barrierefreiheitsstärkungsgesetz) implemented in the new design?
Not fully. While the technical platform can support it, Stéphanie Summermatter shared that the bigger challenge is the text itself. Many abbreviations carried over from the print editions impact readability. Earlier tests to automatically resolve these didn’t succeed, but the team plans to revisit this as AI tools improve.
Q4. How is the review process managed?
The main workflows are handled in Jira. Editors create issues directly from within XWiki, track the status of articles, and coordinate tasks. The process moves from drafting to external expert review, then through internal approval.
Q5. Are friendly URLs possible? For example, instead of numeric IDs?
XWiki supports friendly URLs. By default, it generates human-readable URLs based on the page hierarchy and page names rather than numeric IDs. For example, a typical URL might be /xwiki/bin/view/Projects/Documentation instead of using numbers. However, the URL format can be customized based on instance configurations.
Q6. Is automatic translation over APIs available as a first draft?
Yes. XWiki provides extensions that connect to services like DeepL. You can create machine translations as a starting point and then edit or review them manually.
Q7. How does XWiki performance compare to Confluence or other CMS at scale?
Each translation is a separate page so in practice the size of HLS is around 3 times the number of articles in terms of pages, which means around 105,000 pages. (As Romansh is not used in a lot of pages yet.) Other XWiki clients run millions of pages. Performance tuning (like adjusting caching and using external Solr search) keeps the system responsive. Cold caches can slow initial page loads, but warm caches deliver solid performance.
Q8. What measurable improvements have you seen since switching to XWiki?
- Editors can preview content in real time, including images.
- Workflows are clearer thanks to Jira integration.
- Publishing is faster and more predictable.
- New articles automatically appear on the homepage.
- Overall, the team has more clarity, speed, and control.
Q9. How can we handle performance tuning as the wiki grows?
XWiki includes options to configure documents and rendering caches. For search, moving Solr to an external instance improves indexing. Clustering is also supported to spread load across multiple nodes.
Q10. How intuitive is table creation and formatting? Will editors need training?
HLS described the WYSIWYG editor as intuitive overall, though learning to use macros was new for their team. They ran 2 to 3 days of training per team to get everyone comfortable.
Q11. How refined is the XWiki extension ecosystem? Are there modules for common needs like project management, diagrams, and analytics?
- Project management: Task Manager, Meeting Application
- Diagrams: Diagram Application (Pro) with draw.io integration
- Analytics: Matomo integration for GDPR-compliant tracking
Q12. How does XWiki handle long titles, deep hierarchies, and link integrity during migration?
HLS did not report problems with deep structures or link breakage. In general, XWiki handles complex hierarchies well and maintains link integrity if migrations are properly planned.
Q13. How much effort does it take to customize XWiki’s navigation and design? Can you get a modern UX out of the box?
XWiki offers a clean default look, but HLS worked with XWiki to build a minimalist, tailored front end that is future-proof. A similar result will require some development effort and close collaboration, especially if you have specific branding or layout needs.
Q14. Which technical roadblocks were most challenging? How do you keep extensions updated?
For HLS, the biggest challenge was moving away from a decades-old XML system, rather than specific technical blockers. They didn’t mention major link issues or namespace problems.
Regarding extensions, XWiki focuses on maintaining strong backward compatibility and continues evolving its migration tools.
Q15. What are your strategies in XWiki to keep the large number of extensions up-to-date? Does XWiki have good backward compatibility?
XWiki puts a strong focus on backward compatibility to reduce the impact of upgrades. Most extensions are maintained to work across multiple versions, and the platform aims to avoid breaking changes whenever possible.
When updates are needed, the core team provides clear release notes and migration guides to help users adapt. The Extension Manager in XWiki also makes it easier to track which extensions are installed and when updates are available.
Because XWiki is open source, customers and partners can contribute improvements and fixes over time. This shared maintenance helps keep the ecosystem healthy and current.
