Workspaces, projects and teams

Translation Studio has three layers. Understanding which is which saves a lot of hunting for a setting that lives one level up or down from where you looked.

• A workspace is an organisation’s space. It holds people, settings, and documents.
• A project is one translation job inside a workspace. It holds the documents being translated and runs them through the pipeline.
• A team is the people on a project.

In the left sidebar, Workspaces expands to show the projects inside each one. Teams sits separately, because it answers a different question: not “what work exists” but “what am I part of”.

Workspaces

A workspace is the top level. Everything else belongs to one.

It holds:

• Members, each with a role.
• Translation rules, the defaults every project in the workspace inherits.
• Documents, in private storage belonging to that workspace alone. Access is decided on the server, never from anything the browser sends.
• A change history, so who changed what stays answerable.

Two roles exist above ordinary membership:

• A Workspace Administrator can change settings, invite and remove members, assign roles, and view the change history.
• A Platform Administrator works across every workspace, and is a platform role rather than something granted inside one workspace.

Create a workspace from Workspaces in the sidebar. You choose a display name and a short URL keyword that identifies it.

Projects

A project is one translation job: a set of source documents, the rules to translate them by, and a record of what happened.

Each project has:

• Its own documents. Uploaded files can be reused across projects in the same workspace rather than uploaded again, and each project also gets its own private storage.
• Rules that start from the workspace defaults, which you can override for this project alone. A project with different requirements does not force you to change the workspace.
• A lifecycle, shown as phases with a status: waiting, executing, completed, failed, or skipped. Translation, validation, and back translation are the stages you will watch most.
• Logs and artifacts, so a finished run can be inspected rather than taken on trust.

Projects are created and started deliberately. You press start; nothing begins on its own. A project that fails can be retried rather than being stuck, and a project can also be executed unattended by an external worker process instead of being driven in the browser.

In the sidebar, each project shows a status dot: green for complete, red for failed, amber while work remains. It refreshes on its own, so a project running in another tab still updates here.

Teams

A team is the set of people on a project. There is no separate thing to create: joining a project’s team is how you get access to that project’s work.

Teams in the sidebar and at /app/teams lists the projects you belong to, with a link into each one. If you have just arrived and it is empty, that is expected, and nothing is wrong.

Browse and join a project is how you get onto one. It lists projects in your workspace that are open to being joined. This needs permission, so if you see a message saying you cannot browse and join projects yet, ask a workspace administrator rather than assuming it is broken.

You can also be invited to a project directly, which arrives as a link by email.

Which layer holds what

If you want to change	Go to
Who is in the organisation, and their role	The workspace
Default translation rules for all work	The workspace
Rules for one job only	That project
The documents being translated	That project
Who works on one job	That project’s team

Related

• How a language package is built, for what the translation rules are made of and where they come from
• Library review, for how contested terminology gets settled by speakers of the language