Quality

Reviews

Every translation goes through a review process to ensure quality. Reviewers can approve translations or reject them with feedback.

Translation statuses

Each translation moves through a lifecycle of three statuses:

StatusMeaningWho can set it
Draft Initial state. The translation is new, being edited, or was reset. Automatic, or a reset
Translated Content has been filled in and is ready for review. Translator, Owner
Reviewed Approved by a reviewer. Ready for production. Owner

There is no Rejected status. A rejected translation is a Draft with a reason attached: rejecting clears the reviewer and moves the entry back to Draft, and the comment the reviewer had to write is what tells it apart from a draft nobody has looked at yet. The editor's Rejected filter finds exactly those.

The review flow

1

Translator adds content

A translator fills in the translation. The status is automatically set to Translated.

2

Reviewer checks quality

A team member reviews the translation for accuracy, tone, and completeness.

3

Approve or reject

If the translation is good, approve it. Rejecting requires a comment explaining what needs to change.

4

Revise if rejected

A rejected entry sits in Draft with the reason attached. The translator revises it, which makes it Translated again and ready for another look.

Approve & reject

Approve

Mark a translation as reviewed. The status changes to Reviewed and shows who approved it and when.

You can approve directly with one click, or choose Approve with comment to add context — for example a note about a specific phrasing choice or a reminder for future reference. The comment is optional and does not block the approval.

Reject

Request changes by rejecting a translation. A comment is required when rejecting — explain what needs to change so the translator knows what to fix.

The status moves back to Draft, the reviewer and the review date are cleared, and the feedback is posted as a comment so it stays visible on the key. Once the translator revises the translation it is Translated again, ready for another look.

Who can review

Approving and rejecting are Owner actions, on main and on a branch alike. A Translator fills translations in and can reset them to draft, but cannot mark one reviewed — so a review is a second pair of eyes by role rather than by convention.

Bulk actions

In the translation editor, you can use bulk actions to speed up the review process:

  • Approve all translated — move every entry that is in "Translated" to Reviewed. Owners only.
  • Reset all to draft — move every translated and reviewed entry back to Draft. Owners and Translators.

Filtering by status

The translation editor lets you filter keys by status to focus on what needs attention:

AllMissingTranslatedReviewedRejectedNeeds attention

Use these filters to quickly find keys that are missing translations, need review, or have been rejected. What each one selects is on the editor page, with the search and the file filter beside it.

Branch review progress

When working on a branch, the branch banner shows a review progress bar with the percentage of reviewed operations for the current locale.

On a branch it is the branch operation that carries the status, not the translation on main. Approving an added key approves the value that arrived with it, and a rejected operation goes back to Draft with its comment exactly as a translation on main does.

Change a value again after that approval and it waits for a reviewer on its own account: the branch counts it as outstanding and holds the merge until somebody answers it. Approving the key again answers it, so a key with many languages is still one click. The same applies to a key you fill in every language — Mergua marks the key itself as complete once nothing is missing, which is not the same as somebody having read the translations, so those values wait for a reviewer too.

Progress bar

The progress bar shows how many branch operations have been reviewed for the current locale. It displays a percentage and the ratio (e.g. "50% · 3 / 6 reviewed").

Needs attention

When unreviewed operations exist, a "needs attention" badge appears in the branch banner showing the count of unreviewed items. Click it to filter the editor to only show those entries. Click again (or choose another filter) to show all entries.

What is waiting on you

Reviews in the app header answers one question across every project in the organization: is anything waiting on me. There are three lists. Two of them follow from your role — Owners and Maintainers hold both, a Translator holds only the second — and the third, mentions, is held by everyone, because being named in a comment is not a permission. Where you hold more than one list there are tabs; where you hold one you get it straight, with no tabs at all.

Waiting for your review

Open branches that still carry operations nobody has approved — for Owners and Maintainers. Each row shows the branch, who opened it, how long it has been waiting and how much is left to review. Clicking it opens the editor on that branch with the Needs attention filter already on, in the language that has the most left to review — so you land on the rows the count was about. A branch whose only unreviewed work is a new, renamed or deleted key opens in the project's source language, since those operations belong to no language and show up whichever one the editor is standing in.

Came back to you

Your own values that a reviewer sent back, with the comment they sent back — for Owners, Maintainers and Translators. Clicking a row opens the editor on that branch with that key already selected, so you land on the value the comment is about rather than looking for it. A rejected key operation — added, renamed, deleted — leads to the branch instead, since it belongs to no single language. Once you rewrite the value the row is gone; there is nothing to dismiss.

Mentions

Key comments that named you with an @ and that you have not read — for every role, a Viewer included. Each row shows the key, the language, who asked and what they asked, and clicking it opens the editor on that key and language. This is the one list that empties itself: a mention is marked read the moment the comment thread is on screen, however you got there, and there is a tick on the row for closing one without opening the editor at all. Nothing else here has a read state, because nothing else needs one — a review stops waiting once it is reviewed, and a rejection once it is fixed.

Grouped by project

Every list groups its rows under the project they belong to. The order is by waiting time in both directions: rows inside a project have the longest wait first, and the projects themselves are ordered by their own oldest row — so the thing that has waited longest is the top row of the top group, and a project with many recent items cannot climb over one with a single old one.

The number beside the link

It is how much is waiting on you across all three lists, not how much is new. The review and rejection halves are worked out fresh every time it is shown, from the same count the merge gate uses, so they agree with the review progress on the branch card; unread mentions are added to it, which is what leads you to the tab. When nothing is waiting there is no number at all. There is no notification centre and nothing here is pushed at you — with the two exceptions below, both of which are email and both of which you can switch off.

An asked-for review arrives by email

Everything else on this page waits for you to open it, which is right for a list that answers “is anything waiting on me”. Asking for a review is different: somebody has finished and is saying so. So when a branch is sent for review, everyone in the organization who can approve one gets an email naming the branch, the project, who asked and how many changes are waiting — everyone except the person who asked. It links straight back here, where the branch is already sorted to the top of the list.

The email is a shortcut to this page and not a second channel: the request stands in the list whether or not the email arrives, withdrawing a request sends nothing, and asking twice sends nothing the second time.

A mention arrives by email, collected

Being named with an @ is the other occasion somebody is saying something to you rather than leaving it to be found. So a mention is emailed too — but not one message per mention. Mentions collect for about five minutes, and the mail that goes out at the end of that carries every mention of yours still unread in that organization, including ones named after the window opened. So being named four times in one editing session is one email, and the window starts when the first mention is written rather than being pushed back by the next one. Being named in two organizations inside one window is the one case that costs a second mail: the count has to be a number you can then see on this page, and this page shows one organization at a time.

It names who mentioned you, the project and how many are waiting, and it links to the mentions tab here rather than to a single key, because with two mentions in it every direct link would be the wrong one. The comment text itself is not in the email — the thread is where it stays. A mention you have already read in the app before the window closes is not emailed at all, and naming yourself in your own comment sends nothing.

Switching both off

One switch covers both, under Settings — or from the unsubscribe link in either email, which does not ask you to sign in first. Account email is never affected: verifying your address, resetting your password and an invitation to an organization all arrive whatever the switch says. Turning it off costs you the nudge and not the work — every request and every mention still stands in the lists on this page.

Comments

Every translation key has a comment thread. Use comments to discuss context, provide feedback, or leave notes for translators. Comments show the author, timestamp, and content. Rejection feedback is automatically posted as a comment for visibility.

Type @ in the comment field to name somebody in your organization. Pick them from the list — arrow keys and Enter, or a click — and the mention appears in Reviews for them until they read the thread. The comment keeps the text you typed, and the name is looked up fresh each time it is shown, so a member who changes their name is shown under the new one in comments written long before. Mentions are for the key thread only, not for the comment a reviewer writes when rejecting a value — that one already has an addressee.