What changed, when it changed, and where to read the rest.

Only half of the switch used to be per tab. What a tab displayed and which roles it gave you stayed with the organization you had opened it in, while everything it sent to the server quietly moved to the newly chosen one — so a tab could list one organization’s projects and create the next one somewhere else, and an action your role allowed here was refused as though it did not. Which organization each tab is in is now settled per tab and survives a reload; a newly opened tab still starts in the one you chose last.

The tables asked about branches, formats, pipelines and tooling, and about a person they asked nothing: the word notification appeared nowhere on any of the four, on the one dimension where the older products are traditionally strongest. Their side of the row is read out of their own documentation and dated like every other row — Lokalise reminds a reviewer who has not acted on a task, Crowdin chains a proofreading task to the translation task before it, Phrase sends a reviewed key back for review when it is edited again, and Tolgee blocks a review task until the translation is done. Three of the four win the row, and each says why beside the table: notifications there reach Slack, Teams or a channel of your choosing, and two of the three let you pick them per event. Mergua has the queue and two emails, and the row says so.

The webhook shipped at the end of August and was named in the reference and on the feature tour and nowhere before them: not on the page most readers arrive on, not on the pages that set Mergua against Lokalise, Crowdin, Phrase and Tolgee, and not in the CI section of the Angular, React and Vue pages, which described the pull and stopped there. Each comparison page carries the question as a row now, with their answer beside ours and a link to their own documentation — which is also where you can read that three of those four retry a delivery that failed and Mergua does not.

The plan and the card belong to the organization, so buying one has always been Owner work — but the button said nothing about that and the click did nothing at all: the request was refused and the refusal was dropped on the floor, with no message anywhere on the page. The button itself stays for every role, because a price list without a way to act on it is no use to somebody about to go and ask their owner, and a failure that is not about your role now says so too and can be tried again. New project went the other way and is simply absent for the three roles that cannot create one, in the project list and on the organization settings page alike, with the empty project list naming who adds the first one instead of describing a button that is not there. Owners see all of it exactly as before.

A send-back used to reach the row through the translation alone, so a key a reviewer had refused looked exactly like one nobody had opened: no mark, no reason, and the one filter built to collect send-backs walked past it. The reason existed only in the review comment on the operation itself, on no screen a translator opens. It was easy to miss while an added key was approved again by the system as soon as its last language was filled; that stopped in the release before this one, so the key now stays open and holds the merge until somebody answers it — which is what made the silence worth fixing. The key tree, the list and the table mark the row and carry the reason in a tooltip, the open key writes it out, and a refused deletion reads the same way. The two answers stay apart: an approved translation under a refused key reads as exactly that, and editing the translation resubmits the translation — the key waits for a reviewer either way.

The Send invite button gave no sign that a request was already running, and the check behind it read the pending invitations before writing one, with nothing in between. Two clicks therefore put two rows on the members list and two mails in the invitee's inbox, each carrying a different link, and only one of the two links was the one the list would later resend. The rule now lives in the database — one open invitation per address per organization — so it holds whichever way the second request arrived: a second click, a second tab, a second Owner, or the API. The button also locks itself and shows a spinner for as long as the request takes, and unlocks if the invitation is refused so you can fix the address and send again. Two things are deliberately unchanged: an invitation that has expired can still be issued again and comes back with a fresh link, and somebody who accepted an invitation, left the organization and is invited again gets a new invitation without the record of the first one being overwritten.

The dialog is open to every role on purpose — it is where you go to see what a merge would do, and the Merge button sits under a line naming the roles that may press it. What was missing was the answer above that line: the request behind the deletion summary asked for a merge role, came back refused, and left an empty box with nothing to say it had failed, which reads as a branch that deletes nothing. Reading what a merge would cost now goes with reading the diff beside it and belongs to every member of the project; merging itself is unchanged and still belongs to Owners and Maintainers. If the summary genuinely cannot be loaded the dialog says so and holds the merge, rather than quietly dropping the confirmation step that guards a deletion.

A Viewer used to get the whole working surface: editable cells in all three views, New key, rename, delete, the context note and character limit, the comment box, AI translate, undo on a branch change. Every one of those posted, came back refused, and left a red message — the only way to find out which parts of the screen were yours was to try them. Nothing a Viewer could read has been taken away: the status of each entry, the original text, who translated it and when, the history, the placeholder warnings and a branch list of what has changed are all still there, and so is every download. Owners, Maintainers and Translators see exactly what they saw before.

A Viewer could start a sync and get two steps into it before being told no. The dialog came first, warning that their branch versions might be overwritten, and the refusal came after it in red — for an action the server was never going to allow. Owners, Maintainers and Translators keep the button and its source-branch menu unchanged, and every role still opens the diff to see where the branch stands.

Merging is Owner and Maintainer work, so the button used to sit there switched off for everybody else — and everything it had to say was about the branch rather than about the reader. A Translator on a fully reviewed branch was told that no changes still needed a review, beside a button that was off for another reason entirely; a Viewer was told the count was still being fetched, and then that it could not be fetched, for as long as the branch stayed open, because reading that count is itself something a Viewer may not do. Every role still opens the diff and sees what a merge would take, and the Merge button there names the two roles that may make one.

That check runs again after every edit, and a connection dropped for one of them used to throw the answer away: the control then read nothing on this branch is waiting for a review yet, over work that was, until the next edit or a reload. An older count serves the reader better than none, because clicking is checked once more on the server, which refuses with a reason it can name. Opening another branch still clears the numbers, since a count from the branch you just left is wrong rather than old, and where no answer has arrived at all the merge button says the check did not come back rather than that it is still running.

The button used to report success whenever the request itself succeeded, and it renewed the invitation link before attempting the mail — so an outage at our mail provider left the invitee with a dead link, no replacement sent, and nothing on the owner screen to tell that apart from a resend that had worked. The new link is now written only once a mail is carrying it, and an address that cannot be delivered to at all is named as such rather than as a failure worth another press.

Approving an added key still approves the values that arrived with it, so a key added in eight languages is one decision and not nine — what changed is what happens to a value edited after that approval. It used to count as part of the key whatever state it was in, so the branch read as fully reviewed over a translation nobody had looked at, and the reviewer who released the branch released something they had never seen. Nothing was ever published as approved that was not: the value reached main unreviewed and turned up in the main review list — but away from the branch it came from and the person who approved that branch. A value a reviewer sent back with a comment on it disappeared from the count the same way. The same now applies to a key you fill in every language: Mergua marks the key complete once nothing is missing, which is not the same as somebody having read the translations, so those wait for a reviewer too — and one approve on the key still answers all of them at once.

Until now the mention stood in the Reviews list and nowhere else, which is the wrong place for the one thing on that page addressed to a single person: a terminology question sat there until whoever it was for happened to open the page. The window starts when the first mention is written and is never pushed back by the next one, so being named four times in an editing session is one email rather than four, and it is not postponed for as long as the work continues. Every mention of yours still unread in that organization travels in it, including ones named after the window opened; being named in two organizations inside one window is the one case that costs a second mail, because the count has to be a number the Reviews page can then show you and that page holds one organization at a time. It links to the mentions tab rather than to a key, because with two mentions in it every direct link is the wrong one. What is not in it is the comment: the thread is where the words stay, and the mail is a shortcut back to them. A mention you read in the app before the window closes is never mailed, naming yourself sends nothing, and neither does a project that has been archived or an organization you have since left. Switch it off under Settings or from the link in the mail without signing in — the same switch as the review request, and account email such as a password reset is unaffected either way.

The request itself already stood at the top of the Reviews list, which only helps the reviewer who happens to open the page — for somebody who finished on a Friday that is Monday. The email goes to every Owner and Maintainer except the person who asked, and it links back to the Reviews page rather than to the branch, because that page is where the request is already sorted to the top. Withdrawing a request sends nothing, and asking a second time sends nothing either. It stays a shortcut to a page that works without it: the request stands in the list whether or not the email arrives, so an email lost to a mail server having a bad afternoon costs you the nudge and not the review. Switch it off under Settings, or from the link in the email itself without signing in — account email such as a password reset is never affected. Mentions still send nothing.

A question in a comment thread used to reach whoever happened to open that key next, which for a terminology decision meant nobody. Pick a name from the list the @ opens — arrow keys and Enter, or a click — and it is filtered by name and by email address, so a colleague whose display name says little is still findable. The mention is the one thing on the Reviews page that is marked as read: everything else there stops waiting on its own, a review once it is reviewed and a rejection once it is fixed, while a question would otherwise stand in the list forever. It is read the moment you have the comment thread on screen, however you got to the key, and there is a tick on the row for closing one without opening the editor. The comment stores what you typed rather than a marker, so somebody who changes their name is shown under the new one in comments written months earlier. A Viewer now has a list on that page too, which they never had before. Mergua still sends no email about any of this.

Until now the only way round was your side asking ours — a scheduled pull that either ran too often or found nothing. A webhook is one URL per project with a signing secret shown once at save, and a branch filter that defaults to main, because a hook firing for every intermediate state of every branch is one nobody can leave switched on. Two events arrive: one for translations having changed and one for a branch having been merged, the second tested against the branch that was merged into. The body names what changed — the branch, the language, the file, how many keys moved and where their statuses now stand — and never the translations themselves, which would be out of date on arrival and are what your pull is for. Changes are collected for about a minute before one delivery goes out, so an import of four hundred keys is one call rather than four hundred; a merge is sent at once. A failed delivery is not repeated, and the status of the last attempt is on the card in the project settings, so keep a scheduled pull as your floor.

The option was there on a branch but greyed out, which is where a translator’s returned file most often lands, so the one route that needed it was the one route without it. It was held back because a branch does not write values, it records changes a merge replays later — and nobody wanted approving a German translation to quietly approve a change to the English original in the same click. That is what the separate rows are for: the diff lists a changed original on its own line, in the source language, and it can be rejected while the translation of the same key is approved. The step-3 diff and its keep-or-replace choice are resolved against what the branch shows, so an original the branch has already changed is not offered as a conflict a second time. Merging a changed original writes it to main like any other value; no other language of that key is touched, which is what editing an original in the editor has always done.

It was two steps, and both of them mixed questions you could answer straight away with answers that had to be read out of your files or worked out from a diff — so the dialog made you keep track of what already counted and what did not. Each step now holds one kind: the mode and the target branch first, because both change the meaning of everything after them; the drop zone and everything a file states about itself second, including the target language and how many files this project keeps per language; the diff, the keep-or-replace choices and the source-text option last, because none of them has an answer until Mergua has compared your files with what the project already holds. A key-only import never raises the conflict question, which has no meaning for a file carrying no translations. The common path costs one click more than it did.

An XLIFF 2.0 document states the language it is for on its root element, and Mergua already refused a document that disagreed with the language you had picked — so you were being asked to guess something the file knew. Now the field shows the language and says it came from the document; a file that names none, and every JSON upload, is asked as before. A .json and a .xlf together keep the select, filled in from the document and yours to change, because JSON carries no language. Two documents for different languages are named as such before the import rather than one of them failing halfway, and so is a language this project has not added yet.

A project fed nothing but .xlf files ended up with its source column empty and no way to fill it from those same files, because a document states which language it is for and cannot be uploaded a second time as the source language. The box is ticked for you when the project holds no originals for the file’s keys yet, and an original the project already holds differently is shown as its own conflict with its own keep-or-replace choice — so a translation can be taken while the original is kept. The main branch only: a branch records changes for review rather than writing values, and a change to an original has no place in that queue. A document whose source language is not the project’s is named rather than imported.

Getting a language to an agency meant converting the JSON by hand, or asking the agency to take JSON instead. A document is one language pair, so the format is offered one locale at a time: the all-languages download stays JSON or ARB, and a language split across several files travels as one file section each inside the single document rather than as a zip. The Public API answers it too, while mergua.sh does not carry the format at all — the script writes the files your Transloco runtime loads, and this is not one of them. The reader takes 2.0 only, so a 1.2 file is refused by name rather than half-read, and what it cannot map — inline codes, keys marked as not translatable, attributes Mergua has no field for — is named in the import dialog and kept rather than dropped.

They combine, so “mine, waiting for review” is one question rather than three passes. The list had one control before this — a sort select — and every branch as a full-size card, so forty branches were a kilometre of scroll and finding one meant reading all of them. The sort select gained “waiting longest”, which reads the oldest change nobody has approved rather than the last time the branch was touched — the same order Reviews puts your organization in. Above ten matches the list is paged, and when a filter leaves nothing the list says it is filtered instead of saying there are no branches.

Whether anything was waiting on you used to be visible only from inside a project, on that project’s branch page — so with four projects you checked four places, and with ten you stopped checking. Either way a click lands you in the editor on the right branch: a branch waiting for review opens filtered to what needs attention, in the language with the most left to do, and a value that came back opens with the key already selected. The number beside the link is how much is waiting on you; at nothing there is no number. It is worked out fresh each time from the same count that decides whether a branch can be merged, which is the other half of this change: the review percentage on a branch card used to divide by every operation on the branch, so a branch that added one key in three languages sat at 25 % after the single approval that made it mergeable. The bar is now full exactly when the branch can go in. Nothing here is marked as read, nothing is emailed, and there is no notification centre.

It had never worked. Every click answered with an error: the request was being handled as an attempt to remove a member called “leave”, which no organization has, and which only an Owner would have been allowed to try. The item is shown to everybody except Owners, so it failed for exactly the people it was for. A sole Owner still cannot leave, and is told to transfer ownership first.

No billing, no invitations, no role changes, no project settings — which includes the approval switch itself, so the role cannot lift the gate it exists to serve. Approving a translation and merging a branch were the Owner’s alone before this, and so were the invoice, the member list and the project settings — one role for five unrelated jobs. Making somebody a reviewer meant handing them the billing, so a team ended up with either too few people who could sign work off or more owners than it wanted. Owners hand the role out when inviting or from the Team page; nobody was moved into it.

Removing a language used to delete it, and with it every translation in that language and the entire edit history behind them — the record that would have shown the work had ever existed went with the work. The gate was a Confirm that appeared exactly where the trash icon had been, so a double-click was enough. Archived languages are listed under the language grid, adding one again offers the restore instead of an error, and a push to an archived language reports that it was skipped rather than failing your build. Deleting a language for good is still possible, from that list, once you have typed the locale code — next to the number of translations it is about to remove.

The prompt used to carry the key name, the source text, the same key in your other languages and its neighbours in the file, and stop there. The limit gets one thing more, because a model does not hold a length reliably however firmly it is asked: what comes back is measured against the number, and a value that runs over is left as a draft rather than a finished translation — the same treatment a changed placeholder already gets. Nothing is refused, and nothing about typing over the limit yourself has changed.

They were a card each on the feature tour, and a reader who wanted the mechanism had nowhere to go. What counts as a placeholder in five notations and where the comparison runs; why a rejection is a draft with a reason instead of a fourth status; the note and character limit that travel with a key through ARB. Every chapter of the tour now has a way out of it, in both directions.

Passing --arb used to send the source file as ARB and leave the other languages on runtime JSON, so a description or a character limit corrected in de.arb reached nobody and nothing said it had been dropped. The run reports how many descriptions and limits it changed per language. A key another branch owns, one renamed on the branch, or one the branch has marked for deletion keeps its old notes, exactly as it keeps its old value.

Opening the editor on a phone used to give you a key tree that kept its full width and left about a hundred pixels for the translation, or a table whose column you type into started off the right of the screen. The drawer is what keeps you able to get from one key to the next without searching. Nothing changes on a tablet or a desktop, and the view you picked there is remembered rather than replaced. A tree width dragged wide on a desktop also no longer arrives wider than the window you open next.

It stood two rows tall on any screen, and three on a laptop, with the branch banner under it making four rows of controls above the first key. The menu carries a dot of its own while a single file is selected. The five status filters are one dropdown at every width instead of a row of buttons that only appeared on a wide screen, and every one of these is still reachable by name from the command palette. On a tablet and anything narrower the search field is the magnifying glass that opens that same palette, and on a phone the branch name and the language code drop the icons beside them that only said the same thing twice.

Filling the last empty locale used to approve every value of that key at once — the one just typed, the ones colleagues had written, and anything the AI had returned. Nobody had read them and no reviewer was named against them. Approving the added key by hand still carries its values with it.

The pipeline could pull ARB but never send it, so a description you fixed in your editor stayed in the repo and the one in Mergua kept saying the old thing. Attributes Mergua has no field of its own for come through untouched, and the flag is the whole opt-in — without it an ARB file is still refused, so a stray one cannot be pushed by accident.

The page used to be three cards and their limits. The plan limits in the docs had been written down by hand and disagreed with the ones you are actually billed against; the live figures come from one place now.

They answer the question whether or not you use Mergua.

--format arb, --arb-path and --min-progress had never been documented anywhere, and the reference is the only place the CLI is described, so there is no second copy left to fall behind it.

Turn it on in the project settings, import the files together, filter the editor by file, and download one or all of them.

Uploads are unaffected: the pipeline pulls ARB, it does not push it.