Managing built-in and custom roles
This page explains the role management features available to Pro accounts. See also general information on adding team members.
Default roles
Free accounts provide only a project owner role (with full permissions) and a guest Translator role.
Pro accounts provide the built-in Translator role and two extended roles: Administrator and Developer. You can add more roles, or simply change the defaults. Although the built-in Translator role can't be modified, you can add custom translator roles as you see fit with any extended permissions they require, e.g. API access.
Each role applies a set of permissions as shown in the table below.
Custom roles
Roles you define are attached your account, so they're available when adding team members to any of your projects.
Adding a new role
From the main project management view, the "Team" panel on the right-hand side provides the option to "Manage project roles". Clicking this will bring up a window containing the current list of roles to manage.
Clicking "Add role" brings up a form for you to enter the details of a new role:
- Enter a name and optional description;
- Specify one or more translation permissions, or choose "all languages";
- Optionally select additional privileges for management and developer access;
- Click "Create role".
To assign this role to a new team member you can click the :add icon: from the role list, or select "Add a team member" from the "Team" panel.
Editing a role
The interface for editing a role is the same as for adding one. Click the :cog icon: from the roles list to change its settings.
Editing a role will reassign permissions to anyone with that role. Be aware that project roles are shared across your account so altering them may affect access to more than one project.
Deleting a role
You can delete any role except the built-in translator role. Click the :trash icon: from the roles list to confirm deletion.
Deleting a role does not lock any team members out of their projects. Anyone assigned a role that no longer exists will keep all their permissions until you assign them a new role or remove them from the project.
Translator permissions
In addition to the global permission to translate all languages, you may assign specific languages to a role in advance of adding them to your projects. This is more powerful than adding guest translators in free accounts, because adding guests can only be done on a per-project basis.
This feature allows you to set up custom translator roles.
For example: you could define a role called "French translator" and specify that team members with this role are able to translate into French ("fr") whenever it exists in any of their projects.
You should always choose the least specific locale possible when defining translator roles. This ensures that more specific project locales are always matched.
For example: choosing "zh" would grant permission to translate "zh", "zh-CN" and "zh-Hans". But choosing "zh-CN" would not match "zh" or "zh-Hans" as the "CN" region makes it too specific.
Extended permissions
The following shows the individual project permissions that exist in Loco. The labels across the top are the built-in (default) roles.
| ~ | Administrator | Developer | Translator |
|---|---|---|---|
| Translate any language | • | • | • |
| Add project locales | • | • | |
| - Edit any locales | • | • | |
| - Delete any locales | • | • | |
| Add new assets | • | • | |
| - Edit any assets | • | • | |
| - Delete any assets | • | • | |
| Add new tags / flags | • | • | |
| - Rename any tag / flag | • | • | |
| - Delete any tag / flag | • | • | |
| Download spreadsheets | • | • | |
| Developer tools / API | • | • | |
| Add developer attributes | • | • | |
| Edit developer attributes | • | • | |
| Modify project settings | • | ||
| Add project members | • | ||
| - Change member roles | • | ||
| - Remove project members | • |
Administrator hierarchy
Project administrators have full permissions, but this doesn't grant any privileges outside of the project. Account level privileges can be granted separately.
The project owner is automatically an administrator, and out-ranks all other project administrators unless they are also account administrators. This hierarchy dictates who can remove who from a project.
Developer role
The built-in Developer role is highly privileged because it includes the ability to modify and delete items created by anyone. If you wish to define your own (perhaps less privileged) developer role, be sure to keep the following permissions enabled:
Access developer tools / API
Required for obtaining API keys and exporting translations to file. Without this permission the "Developer tools" window will not visible and API keys will not be generated.Add / edit developer attributes
Required for managing asset IDs and contexts which may be critical for your code integrity. Other attributes considered sensitive are shown on the developer tab of the asset properties window.
Resource ownership
Roles with a create permission can edit or delete any items they've added. The respective edit and delete permissions are required for editing and deleting items added by other users. In short: you can always edit your own content.
For example: a custom role with permission to add new assets would not be able to delete an asset created by another user unless they also had the delete any assets permission on the same project.
Team management privileges
Permission to add project members, and change member roles is granted to the built-in Administrator role, but can be added to any custom role. Be mindful when granting team management privileges to otherwise restricted roles, that you're allowing a team member to grant permissions higher than their own.
Although there is no restriction to which roles can be assigned, a team member cannot assign their own privileges unless they possess a higher admin role (project owner, or account admin). However, there is nothing to prevent such a member from inviting themselves (via a separate email address) and escalating their project access as far as non-owner project administrator level.
Restricting project resource permissions is useful for avoiding destructive mistakes and creating a cleaner interface for non-technical admin users, but should not be considered a security measure if team management privileges are also granted.
Deprecated manager role
The built-in Manager role was deprecated on July 4th 2026, and is only shown if it's already assigned to at least one existing team member.
Please read the announcement for more detail on this change.