start

# Permissions in Pootle

This page tries to specify how different rights are assigned, managed and determined. For in formation on the roles mentioned here, see roles. This page is not a user manual or configuration recommendation, it is for the specification of how Pootle should implement these rules.

## Defaults

Mostly, no role will necessarily have or not have specific rights. However, some privileged rights should never be available to unprivilaged or anonymous users. Pootle will allow users with certain privileges to assign certain rights to certain roles. A user that is operating in that role, will have the rights assigned to that role. Certain rights can also be assigned directly to certain users.

The following describes possible defaults, and give a reasonable idea of what the different roles will involve.

- anonymous users only view translations, register or log in
- identified users can only suggest translations, and apply for team membership
- team members can translate strings
- by default, a language supervisor is supervisor for all projects in the relevant language without an explicitely assigned supervisor
- in the projects for which they are supervisor, language supervisors can
  - assign the “team member” role to identified users
  - set goals
  - assign team members to goals
  - set project permissions (who/which roles can translate/suggest/view/review)
  - assign more language supervisors in the language, either for all unsupervised projects, or to be a supervisor in a specific project
- project liasons can
  - read all files
  - update
  - commit
  - get filetypes like ZIP and SDF
- site administrators can
  - appoint project liasons
  - appoint language supervisors
  - add and update languages (plurals, etc.)
  - add and update projects (VCS info, description, etc.)
  - do user administration (enable, etc.)

## Use cases

Here are some use cases to reflect possible scenarios:

### Use case 1

The site administrator adds Afrikaans and Zulu as languages, and add the PO files to translate one project. Because it is a small site, the administrator sets site wide privileges to enable all identified users to translate. This is very similar to the default Pootle setup in versions around 0.8 - 0.10. The PO files can be downloaded and used, sent upstreamed or packaged in a distribution. The site admin can update translations from POT files.

### Variation 1A

Assume the same setup as use case 1. The site administrator now appoints a project liason B. B is now allowed to update the POT files used inside pootle and commit the translations to CVS.

### Variation 1B

Assume the same setup as use case 1. The site administrator wants to protect against vandalism or accidental overwiting of translations in the wrong language. Therefore translation teams become necessary. The default right in use case 1 that allow al identified users to translate, is revoked, and only team members are allowed to translate. Existing users now only have “suggest” rights and need to apply for team membership. The site administrator can approve these applications. Team members can translate as they could before as identified users.

### Variation 1C

Assume the same setup as use case 1. The site administrator wants to configure Pootle for use at a Translate@thon event, and no accounts are necessary. The site wide default is configured that anonymous users can translate.

### Variation 1D

Assume the same setup as variation 1B. Chinese volunteers want to join, but the site administrator doesn’t want to be concerned with the administration of the extra language. User X registers, and the site administrator appoints X as language supervisor for Chinese. As other Chinese translators register, X assign team rights to the new translators. Because the site wide permissions are that team members can translate, X don’t need to change any permissions to allow the Chinese team members to translate.