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.
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.
Here are some use cases to reflect possible scenarios:
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.
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.
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.
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.
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.