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

Until now a webhook could be saved on Free, where it started a job that could not fetch anything. On a plan without API access the webhook card cannot be saved and an existing webhook sends nothing, but it stays in the settings to be seen and removed. The plan comparison in the billing tab says when a change would switch one off.

Until now the checkout carried exactly the interval you had picked, and the button under the plan comparison always picked monthly. A promotion code you arrived with stays applied when you switch. Once you are subscribed, the interval is still changed in the billing portal.

Until now it led to the start of the billing portal or to the plans dialog, where you had to find the plan a second time. A subscription keeps its billing interval; a first subscription from here is monthly, and yearly is still offered under Change plan. Coming back from Stripe now lands on the billing tab rather than your account settings.

Until now these controls looked available and answered with an upgrade message only after the click. The count is the one the limit is checked against: archived languages and projects count, and so do open invitations. At the language limit a project can still add a language another project of the organization already has, and the picker offers exactly those. An owner gets a link to the billing; everybody else is told to ask an owner.

Until now these controls looked available and answered with an upgrade message only after the click. Branches and keys made before a downgrade stay listed, and a key the plan refuses says so beside its name. An owner gets a link to the organization’s billing; everybody else is told to ask an owner.

Until now the bars only measured the current plan, and the plan cards said nothing about your organization. A lower plan lists the features it lacks with your own numbers, such as the active API keys it would refuse; a higher one the room and the features it adds. Picking a plan changes nothing, and the button beside it leads to the usual place to change plans.

The footer had an email link and a Support link that both opened your mail client, and without one configured neither did anything. Signed in, your name and address are filled in. The addresses are still listed under the form.

Every step is a screen in Mergua, so the pipeline job is the CI tab’s own output rather than a second copy in the tutorial. The pipeline sync docs link to it.

Protected terms have no tutorial of their own, because a missing term is one more QA finding. The editor docs link to it from the QA checks section.

Every frame is taken as the person acting in that step, so the reviewer’s screens and the translator’s show the controls each role has. The reviews docs link to it.

It is also the way in from another platform: export each language as JSON there and follow it from the first step. The import docs link to it.

It picks up where inviting a translator ends, and every screenshot shows what the Translator role sees. The editor docs link to it.

It continues the project of the first two, with a screenshot per step. The User Management docs link to it.

It continues the project of the first tutorial, with a screenshot per step. The Branches and Reviews docs link to it.

Each step links the docs page that explains it, and Getting Started links back. Tutorials are listed under Product in the footer.

Until now it was saved under the language, so two files downloaded one after the other were both en.json. The file called default, the filter on All and a project with one file keep their names.

Until now they exported only the file called default, or nothing when no file had that name, while the list above showed the keys of every file. Under a filter each row counts the shown keys of every file it exports. A project with one file downloads as before.

Keys no longer used in code had to be deleted one at a time. Without a filter there is no delete-all. On a branch each key becomes its own deletion for review, merged like a single delete; on main a key a branch is still working on is kept, and the message names the branch. The command palette offers the same action.

Until now the AI round only filled empty values, so a draft that had lost a placeholder had to be fixed by hand, one key at a time. Translated and approved values are never overwritten, and a value somebody accepts while the round runs is left alone. The command palette offers the same action.

Until now the downloads took the whole language whatever the list showed, so filtering Missing and picking XLIFF still handed an agency every key. Without a filter nothing changes. JSON and ARB leave out a key with no value, so a row whose file would be empty is greyed rather than handing out an empty file. The command palette offers all six downloads.

Until now Pro and Business were charged per member, and adding or removing one changed your subscription. Each plan now includes a number of members instead, open invitations counted, and inviting past it asks you to move up a plan. A downgrade removes nobody, but while an organization has more members than its plan includes, nobody new can join, invitations sent before the downgrade included. Starter has no branches or review workflow; those stay on Pro and Business. Business now has a monthly AI translation allowance like every other plan.

Until now a translator could upload a document with final segments and so approve their own work, on main and on a branch, which made a branch mergeable that nobody had reviewed. The value is still imported; only the approval waits for somebody who may give it.

Until now the Free plan could approve and reject everywhere, although the plans list the review workflow on Pro and Business. A branch opened before a downgrade stays mergeable: with nobody able to approve, the project setting that requires approval does not hold its merge. A review request made before the downgrade can still be withdrawn, and an XLIFF segment marked final is imported as translated rather than reviewed.

Until now only the monthly AI translation allowance was enforced. Limits count per organization, so keys and languages add up across every project, and an archived project or language keeps its slot until it is deleted. Nothing you already have is removed: a limit stops the next addition, in the app, through the API and from mergua.sh alike. API access is the exception, because it is not something you add: on a plan without it, an existing key is refused too.

Until now the script reported its pulls in a form the API could not read, so the tab only ever knew about uploads, and a pipeline that pulls every day read as one that only uploads or never ran. Pushes are listed once, as before.

Until now only the job log knew that a pipeline was reporting missing keys. The tab is told the two counts and the namespace, never the key names, and a run that --strict failed is marked failed.

Until now placeholders, character limits and protected terms were the only checks, and uploads reported placeholders alone. All eight now run on every upload and on what mergua.sh pushes, which prints them as a second warning. They report and never block, and a finding that is right for one string can be ignored for exactly that text, until either side changes. In an AI round broken ICU syntax makes the value a draft.

Until now every bulk action took the whole language whatever the list showed, so a reviewer who had narrowed a file down to 25 keys could approve one key at a time or every translated key of the language. Without a filter nothing changes. The search is in the link now as well, so a filtered view copied from the address bar opens on the same keys.

Until now the round translated the default file and silently left the others as they were, while the editor counted their missing values in the prompt above it. Each file is still sent to the model on its own, so a key name that appears in two files gets its own translation in each.

Until now a pipeline that only pulls had no way to learn either. The check writes nothing and compares with what a pull of the same branch downloads. Unused keys never fail the job, and a pipeline that pushes its keys gets the same answer from Key Sync once its manifest comes from the extractor.

Until now a code could only be typed into the checkout, after the click on Upgrade. Without an account you create one first and land in the same checkout afterwards. A percentage is shown as the price per seat; an amount comes off each invoice and is shown beside the price. A code that has expired or been used up says so, and the checkout keeps its field to enter one.

Until now the seat count was set once, at checkout, and an organization went on paying for the members it had that day. Accepting an invitation, removing a member, leaving and deleting an account all count, and the change reaches the subscription within a minute. On monthly billing an added member is charged on the next invoice; on yearly billing they are invoiced right away rather than at the renewal. A removed member is credited against what you pay next.

Until now every price carried a dollar sign while checkout charged the same amount in euros. The amounts themselves have not changed.

Monthly billing stays as it was and stays the default. Moving between the two intervals runs through the billing portal, and a yearly plan cancelled midway stays active until the year you paid for ends. Checkout now also asks for a billing address and takes a VAT number.

Everything else keeps working before the click, from uploading files to merging a branch. The reason is a pre-registered address: an invited member, a key and a webhook all outlive the moment the real owner takes the account over, so none of them is made until the address is proven. Open invitations sent by unconfirmed accounts were withdrawn.

Until now only the key sync and edits in the editor left one, so a branch filled by the pipeline showed nothing on main but the merge. A value pushed back unchanged gets no line, one set back to what the branch inherited withdraws the change along with its lines, and the values of a key the branch itself added get theirs once somebody edits them.

Until now an import or an AI round left the line on whoever had last typed in the cell, and a value the pipeline created showed nothing of the pipeline once merged, only the merge. A value restated unchanged keeps whoever wrote it, so importing an export back takes nobody's name off their work.

Until now one switch covered mentions, review requests and changes sent back together. The summary counts what came in that day, one email per organization, and sends nothing on a day with nothing in it. The unsubscribe link still turns the main switch off.

Until now a rejection reached only somebody already looking at the Reviews list. The reviewer's note stays in the app, an approval sends nothing, and the notification switch in Settings covers this email too.

Until now the thread was part of the panel, which a screen narrower than 768 pixels does not have, so a mention led to the right key with the question nowhere on it. The mention counts as read once the thread is open, not when the key is.

Until now both still read the value as unapproved while the editor showed the approval: the XLIFF unit went out as translated, and a fill upload overwrote the cell. On older branches the history of such a cell also shows again who wrote the text on the target.

Until now the row went on reading as unapproved after the click while the branch bar counted the approval — for one cell at a time, and for a whole screen of rows after Approve all reached the inherited values. The text is still the one the branch inherited, so the row is not marked as changed and the merge carries only the approval. A value sent back instead shows the request for changes on its row the same way.

Until now approving meant one language at a time, and a click that missed a few changes looked the same as one that approved them all. A change a reviewer sent back is left as it is and has to be approved on its own row. A change that has left the branch since the dialog opened is counted as not approved. Approving a language on its own works as before.

Until now it listed only the language the editor was set to, and sent you to the editor's language switch for the rest. A key that was added, renamed or deleted belongs to every language, so it appears under every chip and counts in each, and the language the editor is on stays marked. "Approve all" approves what the chosen chip lists. The conflicts are never filtered, because every one of them has to be answered before the merge.

Until now those cells named whoever had generated the key, so a sync of twelve values read as twelve edits one person had made by hand. A value the pipeline pushes back unchanged keeps the name of whoever wrote it, and editing a cell after the pipeline puts your own name back on it. Existing history keeps the name it was saved with; there is no record of which key wrote it.

The AI prompt has always asked the model not to translate brand and product names, with no list behind it: it guessed which word was meant, and nobody found out when it guessed wrong. Each term can carry a note saying what it is, which is the tooltip in the editor and goes to the model with the term. After a round Mergua checks the answer, and a translation missing a protected term is written as a draft rather than thrown away, so it lands in the filter a reviewer already uses with the value still in the cell. Nothing is blocked anywhere: a word that reads better translated in one string stays the translator's call. A term is matched whole and regardless of capitalisation, so it does not fire inside a longer word and a model that shouted the product name has not lost it. The list only protects — it records no target spelling for anything. Owners maintain it; everybody on the project sees it. Uploads are unaffected.

What decided this before was whether a pipeline had ever run, which answered the wrong question for the reader this was built for: a job somebody wired and then left behind has runs and no description, and that project used to open on Translations like any other. The line under the project name is the quiet half — it is a statement rather than a button, so every member sees it, it opens the CI tab on a click, and it disappears without trace once the questions are answered. The tab only opens by itself once per project per session, so a team that has decided not to describe its pipeline is not moved off Translations on every visit.

The tab used to be a catalogue: five pipeline templates across three providers, with nothing saying which was yours. It is still there, under a disclosure, for looking one thing up or building a job by hand. What is new is that the answers are the source — change one and the sequence, the snippet and the repository list all move with it — and that they are readable afterwards, which is the half this was built for: the person who inherits a pipeline can read how it is wired instead of reconstructing it from the job file. Where the runs show something an answer denies, the block above says so and names both sides. The file layout question is the project setting of the same name, so the assistant and the settings tab cannot disagree about it, and only an owner changes it. A project no pipeline has reached yet opens on this tab.

Those runs were already recorded, as a list of rows on the sync tab, and turning twenty of them into a statement about the integration was left to whoever was looking — which is no help to the person who inherited a pipeline somebody else wired and then left. Four things stay out of reach and the block says which: the file format, the path in your repository, whether only approved translations are pulled, and the git provider are not part of what the script reports. A project that has never synced gets a sentence saying so rather than an empty panel.

Until now those inherited values could only be approved one cell at a time and nothing pointed at them, so a branch could report every change reviewed while carrying content nobody had read — the reviewer found out on main. They still do not block the merge: a branch is not held back because the branch it forked from was behind. Merging carries the approval to the target and never the text, so a value edited there in the meantime keeps the newer wording and is not counted as a change. The wider scope covers the language the editor is open on, and on main the click is unchanged.

Until now the branch list showed whoever had generated the key, so a nightly sync read as four branches somebody opened by hand — and it kept saying that after they had left and their key had been revoked. Existing branches keep the name they were saved with; there is no record of which of them were really the pipeline’s. Keys and translation values written by a pipeline still carry the key owner’s name.

Six tools, four of which only read: the languages and how far along each one is, a search across key names and translated text, the files themselves, and whether a branch is ready to merge. The two that write are the ones an agent reaches for after it has changed the code — one makes a branch’s key list match the source, the other fills in values and reports back any whose placeholders stopped matching the original. Key changes need a branch and are refused on the main line, so they arrive as something to review; values go to the main line unless a branch is named, and replace what is there unless the agent is told to skip or fill. The key is bound to one project, which is why no tool takes a project: there is nothing for an agent to address by mistake. Reviewing, merging and the AI round stay in the app.

Starting a second checkout is how an organization ended up with two subscriptions running at once: two browser tabs, or a reload while the handover to Stripe was in flight, and both could be paid. Only the second was visible to Mergua afterwards, so cancelling it left the first one billing away with nothing pointing at it. A checkout for an organization that is already subscribed now says so and sends you to the portal instead, and two checkouts started at the same moment resolve to a single session. Nothing changes for a first subscription: the plans are still where they were.

Those three pages were written before the review queue, the two notification emails and XLIFF existed, and they had gone on describing a pipeline with nobody in it — the push, the pull, and nothing in between. Each page says it in its own words rather than in shared ones, because the unit both halves are about is a file, and that is the one thing the three stacks disagree on: a scope in Transloco, a namespace in i18next, a file you compose into the messages object in vue-i18n. The webhook paragraph beside it stays shared for the opposite reason — a branch filter and a signature belong to the project, not to the framework — and every mechanism either half names is linked rather than described a second time.

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.