The ticket for a typo
Somebody spots that the checkout button says “Procede”. Fixing it takes four seconds. Getting it fixed takes a ticket, a slot in somebody's sprint, a branch, a pull request, a code review of a one-word diff, and a deploy — and in most teams that is a week, because none of those steps is urgent for a typo.
The same path is taken by every change to the words in an app:
- a call to action that marketing wants to test in a different wording,
- a legal sentence that has to read exactly as the lawyer wrote it,
- an error message support keeps being asked about,
- a product name that changed last quarter and still appears in three places.
None of these is a code change. They take a developer's time only because of where the text is stored, and that is worth separating from what the text is.
Where the words already live
In an app set up for translation, the words are not in the code at all. Every visible string is a key — checkout.submit — and its text sits in a locale file, one per language:
en.jsonsays"checkout.submit": "Place order",- the code only ever says
checkout.submit.
That file is data. Changing a value in it changes no logic, and the build turns it into exactly the same app with a different sentence on one button. The only reason a developer is involved is that the file lives in the code repository, and the repository is theirs.
This works for an app in one language too. A team that keeps its English in a locale file has already separated the words from the code — whether a second language ever follows does not matter. Text written straight into a template is the exception: it has to be moved into the file first, and that part is a developer's job.
Edit, review, ship
Once the file is the thing being edited, a copy change can take the same path a translation takes, with nobody in it who does not need to be:
- Edit. The person who owns the wording opens the key and changes the value, in a browser rather than in a code editor.
- Review, if the team wants one. The change is made on a branch, so it is invisible until somebody approves it — a second pair of eyes on a legal text, or the product owner signing off a new call to action.
- Merge. The approved change lands where the app's release reads its files from.
- Ship. The change starts the deployment pipeline, which fetches the files, builds, and deploys. Nobody opened a ticket.
“Live” here means live with the next build, not live the moment you press save. The words are bundled into the app, so a change reaches users the way every other change does — through the pipeline, and through staging first if the pipeline has a staging step. That is a feature rather than a limit: the text in production is always the text some build tested.
What the developer sets up once
The developer does not disappear from this, they move to the beginning of it. Two things make every later copy change theirs no longer:
- A pipeline step that fetches the locale files before the build, so the files in production always come from where the words are edited.
- A trigger that starts that pipeline when the words change, usually a webhook: an HTTP call to the CI server when something has been edited or merged. Without it the change waits for the next build somebody starts for another reason.
Some things stay with the developer, and it helps to say so up front:
- A new text in a new place. A new key needs a line of code that shows it.
- Text that has to fit. A button that is 120 pixels wide does not care that the new wording is better. A length limit on the key, set by whoever knows the layout, tells the person editing before the build does.
- Placeholders. In
Hello, {name}the{name}is filled in by the code. Removing or renaming it breaks the sentence, so the editor should warn about it rather than trust the person editing to know.
Where Mergua fits
Mergua holds the locale files of a project and lets you edit them in the browser, so the path above is something it already does. It is a translation tool, but nothing in it requires a second language: a project can hold only the language your app is written in, and that language is edited in its own view like any other.
Who does what
- The person who owns the words is invited with the Translator role, which lets them edit every value and open a branch — and nothing in the project settings.
- An Owner or a Maintainer approves and merges. With the project's approval setting on, which is the default, nothing on a branch merges before every change on it is approved — see reviews and branches.
- The developer sets up the pipeline step with the sync script and points a webhook at the CI server. It sends
branch.mergedwhen a branch is merged andtranslations.changedwhen values change, and by default only for main. Edits are collected over a short window, a minute unless the project sets another, so a dozen corrections start one build.
What each plan includes
This is the part to check before promising it to a team, so it is spelled out (pricing has the rest):
- Free: editing in the browser. No API access, so no sync script and no webhook — somebody downloads the file and commits it. The ticket goes away; the developer does not.
- Starter: API access, so the pipeline fetches the files and the webhook starts it. An edit goes straight to main and ships with the build it triggers — there are no branches, so there is no review step before it.
- Pro and up: branches and the review workflow on top, so a change waits for an approval before it reaches main and the pipeline.