[Feedback] How we handled default permissions on our Weblate project

[walpox]

Context

I am a contributor to an open source video game called Veloren. I am writing this article to share how we adapted to the default user permission scheme in Weblate (v5.3.1) to accomplish our intended workflow.
We are translating the game with a Weblate instance hosted by Codeberg.

This is the translation workflow we planned and is currently in use:

1. Languages with one or more dedicated reviewers.
   • (Non-anonymous) Contributors can only add translation suggestions.
   • Reviewers are responsible for checking suggestions and deciding whether to accept or reject them.
2. Languages without any dedicated reviewers.
   • This is the default type.
   • (Non-anonymous) Contributors can both add and vote for translation suggestions.
   • A suggestion becomes the new translation once it reaches a certain number of upvotes.

This way, community members can become dedicated reviewers for languages if they ask to. They become part of a project team with the Review strings role for their language. New languages can still be translated.

The problem

However, we found out that the default way Weblate grants users permissions was incompatible with our workflow.

1. Weblate has an instance-wide team, Users, which every (authenticated) user is a member of automatically.
2. That team grants the Power user role to its members.
3. Our Weblate project was configured with the Public access control setting.
4. Therefore, any Codeberg user, by default, could interact with our project with the permissions granted onto them by the Power user role.
5. The problem: the Power user role grants some permissions we didn't want. These are:
   • Use automatic suggestions
   • Dismiss failing check
   • Edit strings
   • Edit source strings
   • Accept suggestion
   • Delete suggestion
   • Overwrite existing strings with upload
   • Upload translations

To elaborate on the problems with some of these permissions:

• Accept suggestion.
  • When suggestion voting is enabled and the upvote threshold is greather than 0, this permission is not a problem because users cannot accept suggestions.
  • When suggestion voting is disabled, this permission is a problem.
  • Suggestion voting is enabled project-wide with an upvote threshold of 3 votes. For languages with dedicated reviewers, we disable it (customize workflow in language settings). The problem is every authenticated user can accept suggestions besides the dedicated reviewers.
• Delete suggestion.
  • Every authenticated user can reject other people's suggestions. This behavior was undesired.

How we solved the problem

We took these steps to remediate the issue:

1. The Codeberg team created a new custom role, called Less Powerful User, with the same set of permissions that Power user except the permissions listed in the previous list point 5.
2. We created a project team called Users, with the automatic assignment "^.*$" to grant the role Less Powerful User. Missing users notify us and we add them manually. The API was not used to handle membership of this team massively.
3. We changed the Access Control settings of our project from Public to Protected. This way, any authenticated user no longer interacts with our project with the permissions of the Power user role, but instead with the Less Powerful User role. And non-authenticated users (guests) cannot add suggestions anymore.
4. Now, users can only reject their own suggestions and:
   • In languages with dedicated reviewers:
     • Only the reviewers can accept suggestions.
   • In languages with no dedicated reviewers:
     • Nobody can accept the suggestions directly. They need to reach the upvote threshold to get accepted automatically.

Conclusion

The default user permission scheme might be fine for internal use by employees of a company. However, I believe it can lead to problems such as vandalism in other contexts such as hosting, where strangers share the same Weblate instance. On that note, I could accept and reject suggestions on any Public projects I tested in your cloud hosting instance. In your official cloud instance, switching the project to "Protected" in the Access Control settings might not be enough for a project owner to achieve their intended workflow. In our case, the instance administrator had to create a custom role.

One thing to note is that we needed to create a custom role because no combination of default roles could achieve the same set of permissions than this custom role. Some of the default roles always added some undesirable permission to the end-result.

Our translation documentation is available here, in case you find it helpful:
https://book.veloren.net/contributors/translators/index.html

[nijel]

You can also remove Power user role from the built-in Users role and include more fine-grained roles instead.