Injecting Pro Apps project in XWiki's Weblate (l10n)

Hi everyone! I am Stefana, Product Manager of XWiki’s Pro Apps. I am writing in order to get your opinion on injecting a Pro Apps project in XWiki’s Weblate instance.

Short context:

Pro Applications are a set of extensions developed and supported by a dedicated team within XWiki SAS. Like everything at XWiki, Pro Apps are fully open source, under LGPL-2.1 license and you can follow everything that we do, including our roadmap, on github. Our work focuses on applications such as Active Directory Authenticator, Diagram, Confluence Migrator and many others. We wish to inject a project in l10n for better visibility and to not duplicate configurations.

The potential conflict:

By default, Pro Apps are packaged under a license with a free trial which, when purchased, offer the buyer technical support services for said application. When installing the applications from your XWiki instance’s Extension Manager, you will receive the licensed application. If you wish to benefit from support services from XWiki SAS for the application that interests you, you can purchase the “license” which is not a license to use the product, but a maintenance service. If you do not wish to use XWiki SAS’ support and you only wish to use the app, you can request a free license (same features and updates but no technical support) or you can build the app on your own from our github.

The need:

We would like to implement a method of contributing to translations for these extensions, but we understand that our model is not typical and that the commercial implications may not make them appropriate for open source contributions. Of course, if we do inject the Pro Apps project in l10n, we will make sure that the contributor is properly informed and notified that they are contributing to a separate project, with a different model.

Therefore, I would like to get your opinion on this:

  • Would it be in order to inject the Pro Apps project in l10n?
  • Do you see another way to handle this?

Thank you very much for your time!

1 Like

-1 from me. The main reason is that l10n is for XS and contrib projects and the pro apps you mentioned are not contrib projects. See


  • They’re not developed collaboratively
  • They’re not followong the dev rules from
  • They’re not using the contrib issue tracker (
  • Etc (in short they’re not part of the ecosystem)

I’d recommend to set up a weblate instance for XWiki SAS projects. We can help you do that as we have some expertise of doing so.


I think they do.

I understand your point Vincent, but:

  • is hosted by XWiki SAS
  • XWiki SAS is the main contributor for the XWiki Open Source project
  • Some of the money that are used to develop XWiki Standard features come from paid Pro Apps licenses
  • Translating voluntarily Pro Apps on l10n could be a way to support the development of the XWiki Open Source project

Same as we have rules for promoting paid support on (also hosted by XWiki SAS) we can imagine agreeing on some rules for adding paid (open source) apps to l10n, and let the users decide if they want to translate them or not (again, voluntarily). We could also decide to try this for a limited time and see if we receive any translations for the Pro Apps. I know this mix between com and org can be seen as controversial or fishy, but I don’t think we should dismiss the idea too quickly.

+0 on my side, but we need to define some rules.


Disclosure: I’m an XWiki SAS employee, working part-time on Pro Apps

Where is the consistency, why l10n? Why not agreeing to add paid apps to, or xwiki-contrib on github, or, or …?

I make a difference between allowing some advertising of sponsoring companies in some places (as a recognition of their support), but keeping separate the organizations, and allowing sponsoring companies to use the services for their own needs. IMO if we do this, there’s no limit. I’m still very -1.

If we zoom out, I see only 2 options that are logical and consistent:

  • Either is separated from, with its own governance. This is what we have now.
  • Either and merge, because XWiki SAS is sponsoring a huge part of the development of XWiki, and we drop the separation and trying to be an open and neutral ground for XWiki development.


I think I’m also -1: I do see the pros in having a unique translation platform for all XWiki (.org and .com) stuff, but IMO if we mix it in same platform it will bring even more confusion and it’s already not so easy to people to make the distinction between the open source project and the sponsoring company.

As Vincent mentioned, we could easily set up a weblate instance for XWiki SAS projects, and I think we can even probably import some glossaries from there if we want to have some consistency in the translations. Now for having translators in this new platform: to be discussed, but maybe we could put a banner in Weblate to kindly ask translators if they’re willing to also perform translations in Weblate platform with a link. To be investigated we may even have a unique auth system for both platforms (not entirely sure about that one).

I don’t think it would be a problem to have the same list of auth providers than we currently have on Sign in @ Weblate

Sure, but I was more wondering if people with an account created on, not relying on an external auth manager, could use that account to be authenticated in another Weblate instance, and I don’t think that’s true.

What I mean is that at worst we could consider that this need is covered by the use of an external provider.