A Translation Workflow That Actually Works for Teams

Translation is a team sport. Developers know what strings exist. Translators know the languages. Project managers know what's ready to ship.

The problem is that most Laravel setups force all three through the same bottleneck: the repository. LangSyncer is built to fix this.

The Problem in a Real Laravel Team

Picture a five-person team shipping a checkout flow in 6 languages. The strings live in lang files, so every translation change is a code change:

// resources/lang/de/checkout.php
return [
    'shipping' => [
        'title' => 'Versand',
        'address_label' => 'Lieferadresse',
        'submit_button' => 'Weiter zur Zahlung',
    ],
];

Your German translator has never used git. So either a developer transcribes fixes from a spreadsheet into PHP arrays (and becomes the bottleneck), or the translator gets repo access and one Tuesday a stray comma in checkout.php takes down production.

And there's a third failure mode: no gate. Whoever merges last decides what users see. A half-reviewed machine translation for a legal disclaimer ships because nobody owned the "is this ready?" question.

The fix isn't more process. It's separating who can edit from who can publish.

Two Roles, One Clean Boundary

LangSyncer projects have exactly two access levels, documented in full in the projects guide:

Project Admin (account-level)

Automatically has access to every project in the account
Can publish translations
Manages team members, project settings, and API keys

Collaborator (project-level)

Added explicitly, per project
Can create and edit translations, use AI translation, import/export files
Cannot publish, cannot see API keys, cannot touch settings

The full permission matrix:

| Permission | Project Admin | Collaborator | |------------|---------------|--------------| | View and edit translations | Yes | Yes | | Use AI translation | Yes | Yes | | Import/Export files | Yes | Yes | | Publish | Yes | No | | View or regenerate API key | Yes | No | | Manage team members | Yes | No | | Edit project settings | Yes | No |

That publish line is the whole workflow. Everyone can work; only admins can ship.

The Workflow, Step by Step

1. Developer adds keys

A developer building the checkout writes the Blade templates with translation keys and adds the English values in LangSyncer:

{{ __('checkout.shipping.title') }}
{{ __('checkout.shipping.address_label') }}
{{ __('checkout.shipping.submit_button') }}

Creating keys is free and unlimited, and every save is a draft, invisible to the app. The developer ships the feature with English strings and moves on. Nobody is blocked.

2. AI does the heavy lifting

Anyone on the project clicks Translate Missing. 30 new keys times 10 languages is 300 quota units, and the dialog shows the estimated consumption before you commit. Minutes later, every key has a value in every language, all still drafts.

3. The translator reviews

A Collaborator filters the translation list by Pending status (the yellow badge) and works through the AI output: brand voice, formality level, the nuances machines miss. Each save updates the draft. Nothing they do can reach production, so they can work fast without fear.

4. The admin publishes

A Project Admin clicks Publish, reviews the pending changes count (say, 45 new translations and 12 edits), adds a release note like "Added shipping checkout flow", and confirms. Collaborators literally can't do this step: for them the publish button is disabled.

5. Production updates

Publishing regenerates the CDN files (about 30 seconds) and dispatches the "Translations Published" webhook (2-3 minutes) so your Laravel app picks up the changes. No deploy, no PR, no spreadsheet.

Setting Up the Team

The concrete flow in the UI:

First, give the user the Project Collaborator role at the account level. Without it, they won't appear in the project dropdown at all — this is the number one "why can't I add my translator?" issue.
Open the project's Team tab, pick the user from the dropdown, click Add. They're notified and get access immediately.
To offboard, click Remove on the same tab. Access is revoked instantly.

Project Admins never appear in this flow. They have account-level access to every project and can't be removed from individual ones. So the practical model is: make one or two people admins, make everyone else a collaborator on exactly the projects they need. Your mobile app translator never sees the admin panel project.

The Audit Trail

Role boundaries only work if you can verify them. LangSyncer logs the history at several layers:

Version history per translation. Click the history icon on any translation and see every version: the version number, its status (Draft, Active, or Archived), when it was published, and who published it.
Publication records. Every publish creates a record, and the release notes you attach become your changelog. "Fixed checkout button translations" beats archaeology through git blame.
Webhook delivery logs. Each webhook keeps a delivery history with response codes, so you can confirm your app actually received the publish event.

When a string looks wrong in production, the question "who changed this and when?" takes one click instead of a Slack thread.

When This Is Overkill

Solo developers. You're the admin, there's no one to gate. The draft and publish workflow still earns its keep for batching changes, but the role setup adds nothing.
You need finer-grained roles. There are exactly two levels. If you want a "can edit French but not German" reviewer, or a translator who can't spend AI quota, that granularity doesn't exist — every collaborator can edit all languages and trigger AI translations. Set a project quota limit to cap the blast radius.
Tiny teams on Free. The Free tier includes 2 users. A real multi-role workflow (dev + translator + admin) effectively needs Icebreaker, which covers 10 users.

If you're weighing this against heavier enterprise workflow engines with multi-stage approval chains, that's a fair comparison to make: see LangSyncer vs Crowdin for where each model fits.

Gotchas

A user must hold the Project Collaborator account role before you can add them to any project's team.
Publish button greyed out? Either there are no pending changes, or you're a Collaborator — publishing requires Project Admin.
Collaborators can consume AI quota. Pair team access with a per-project AI quota limit so a bulk translation run can't drain the whole account.