Team and permissions

Open the organisation, enter the collaborator email address, and choose their permissions. Pending invitations can be resent or revoked. The invited person signs in and accepts the invitation to join the organisation.

Use organisation settings to review member access as responsibilities change. An invitation and an active membership are different states; check whether the invitation was accepted before troubleshooting project access.

Grant edit access to people preparing translations and publishing access to those responsible for releasing them. Available controls depend on the signed-in account and the selected organisation.

A work package is a named group of keys assigned to one team member, with an optional due day. Only the person who created it, the person it is assigned to and its approver can see it. Team owners get no separate view.

Members with the Project settings permission create a package from the Keys tab: open Actions, select keys, then choose Work package. They choose a team member with the Edit keys permission. They can add keys later from a key's menu or from Actions.

The Work Packages tab of a project lists your packages, newest first. Show keys opens the Keys tab filtered to that package. You can filter by one package at a time and combine it with the other filters.

The assignee marks a package as done, from the Work Packages tab or next to Publish changes, and needs the Edit keys permission. While someone filters by a done package, its keys are read-only in the dashboard. This is a reminder, not a lock: without the filter, or through the CLI or MCP, the keys can still change. The assignee reopens it from the Work Packages tab, and adding keys reopens it too.

A package can have an approver: anyone in the team, also someone with read-only access, but not the assignee. The approver can follow the package read-only and is asked to review it once it is marked as done. They approve it, or reject it with an optional reason, from the Work Packages tab or from the notice above the keys. A rejected package opens again for the assignee with the reason shown, and goes back for approval when it is marked as done again. Without an approver, a package is approved as soon as it is marked as done, with the assignee as approver. Reopening it, adding keys to it or giving it to another assignee clears an approval or withdraws a pending review, without telling the approver. Removing the approver while it waits approves it.

The person who created a package can rename it, change the assignee, the approver or the due day, remove keys or delete it, as long as they keep the Project settings permission. Deleting a key removes it from every package. Deleting a package does not change its keys.

The bell in the header shows your unread notifications, across all your teams. People get a notification and an email when a package is assigned to them or taken away, when their package is done, reopened by new keys or deleted. Approvers are told when they are picked or removed and when a package waits for their approval; creator and assignee are told when it is approved or rejected, with the reason. Nobody is told about their own action. Open a notification to go to its package. Mark notifications as read, delete them one by one, or clear the list.

• Translation workflow overview

1. Confirm that the collaborator is signed in with the invited account.
2. Switch to the organisation that owns the project.
3. Ask an organisation administrator to check the relevant permission.
4. For CLI access, verify that the API key belongs to the intended account and that its organisation permissions cover the operation.