You didn't become a developer to fix typos.
But here it is again. Someone wants "Get started" to say "Try it free" — in three languages. In your app that's a branch, a review, a pipeline and a deploy. For eleven characters.
LangSyncer moves your translations out of the repo, so the people who own the words can change them. Live in production in about 20 seconds. You don't touch it.
Free tier, no card. Import your existing lang files, export them whenever you want.
Hey! Can we change "Get started" to "Try it free"? Also in ES and FR please 🙏
- 1 Find the key across three repos
- 2 Branch, edit, commit
- 3 Open a PR, wait for review
- 4 Merge, wait for CI, deploy
- 5 Realise ES and FR are still English
It's eleven characters.
Sound familiar?
None of this is hard. That's what makes it so annoying. It's just work that keeps landing on the one person who shouldn't be doing it.
"Can you just change one word?"
It's never one word, and it's never just you. It's a ticket, a context switch, a branch, someone else's review and a pipeline — for a sentence that took ten seconds to write.
Interrupted mid-task, twice a week
Nobody knows what is still in English
Someone added three keys last sprint and only filled in the English. You'll find out when a customer emails a screenshot of messages.checkout.title sitting on your pricing page.
Found by the customer, not by you
The translator works in a spreadsheet
They can't see the screen, so they guess at context and blow past the button width. Then you paste 400 rows back into lang files by hand and hope the keys line up.
An afternoon, every language
Half the app was never translatable
The i18n pass covered the marketing pages. The admin panel, the emails and every validation message a junior added since are still hardcoded English, and nothing tells you where.
A migration nobody wants to scope
A typo shipped, and it is still there
You spotted it Tuesday. Fixing it means a deploy, and there's no deploy planned until Thursday. So it stays. It's a comma, and it's on the homepage.
Days of visible embarrassment
Twelve repos, twelve different messes
One project uses JSON, one uses PHP arrays, one uses both. Different key conventions, different coverage, no way to answer "is the Dutch version done?" without opening all of them.
No answer without a manual audit
Every one of these has the same root cause: your app's words live in your code, so only people who can deploy code are allowed to change them. That's the thing worth fixing.
Take the words out of the code
Your keys stay exactly as they are. __('messages.welcome')
still works. What changes is where the value comes from, and who is allowed to edit it.
Import what you already have
Point LangSyncer at your project and upload your existing PHP and JSON lang files. Nothing is rewritten and no keys are renamed — you get the same set you had, in one place, with the gaps visible.
Let the right person edit
A translator, a content owner, your client. Give them access to one project and nothing else. Missing languages can be drafted with AI and reviewed before anyone publishes them.
Publish, and it's live
Approved changes go out over a CDN and your app picks them up in about 20 seconds. No commit, no pipeline, no release window. If you'd rather ship them normally, export back to lang files instead.
$ composer require headwires/translator-client $ php artisan vendor:publish --tag=translator-client-config
One package. Standard Laravel translation keys. Take it out again in a single commit.
You can't translate what nobody wrote down
The reason your app is half-translated is not that someone was lazy. It's that
<h1>Welcome</h1> looks completely
fine in review. Nothing flags it. It ships, and it stays English forever.
Run one command in your project and the scanner reads every Blade template and PHP file, finds the text that was never made translatable, and proposes a key for each one. You approve them in the dashboard, then apply the changes locally and read the diff before anything is committed.
-
Headings, buttons, placeholders, alt text and exception messages
-
AI proposes a key name that matches your existing conventions
-
You review every suggestion before a single file is touched
-
Changes land as a normal git diff — revert anything you disagree with
$ php artisan translator:scan --ai
Now multiply all of that by eleven client projects
One app is an annoyance. A portfolio is a business problem: every client is a separate repo, a separate deploy schedule and a separate person who messages you on a Friday. The hours are real and none of them are billable.
You keep control of your own strings
Putting your app's copy behind someone else's service is a fair thing to be nervous about. Here's exactly what happens in each case you're probably imagining.
What if we stop paying?
Export everything as native Laravel PHP or JSON lang files, commit them, and carry on as before. Your keys never changed, so nothing in your code has to.
What if we don't want a runtime dependency at all?
Run the client in static mode. Translations are synced down into files in your project and your app reads them locally, exactly like normal lang files. Live mode is a choice, not a requirement.
What if the AI writes something embarrassing?
AI produces drafts, not published copy. A draft is invisible to your app until a human reviews it and publishes it. Nothing reaches production because a machine felt confident.
What if someone publishes the wrong thing?
Every change is recorded with who made it and when. Roll a key back to a previous value in one click — no revert commit, no deploy to undo a deploy.
Who can actually edit what?
Roles and per-project access. A translator or a client can be given one project and only the ability to translate in it. They never see the rest of your account.
How deep does this go into our codebase?
One Composer package and a config file. Your templates keep calling __() with the same keys. Removing it is one commit and the lang files you exported.
Cheaper than the deploys
Start on the free tier with a real project, not a sandbox. Move up when the free tier stops being enough.
Free
Put it on something real and see whether it actually helps.
- 3 projects
- 2 people who can edit
- 100 AI translations/mo
- Publish without a deploy
- CDN distribution
- Code Scanner
Icebreaker
More projects, and other people who need to edit the copy in them.
- 10 projects
- 10 people who can edit
- 3,000 AI translations/mo
- Publish without a deploy
- CDN distribution
- Code Scanner
Add quota when you need it. Packs never expire, so a one-off migration doesn't push you onto a bigger plan forever.
7-day trial on the paid plan, no card up front. Cancel whenever — your translations export back to lang files on the way out.
The questions you're actually asking
We already have CI/CD. A deploy takes four minutes. Is this really a problem?
The four minutes aren't the cost. The cost is the interruption: reading the request, finding the key, opening the branch, waiting on a reviewer, and losing whatever you were actually working on. LangSyncer removes the request from your queue entirely, rather than making the deploy faster.
Do I have to redeploy to update a translation?
No. Edit and publish from the LangSyncer dashboard and your app picks the change up in about 20 seconds — no commit, no pull request, no pipeline run. If you would rather keep translations in your repo, static mode syncs them down as files and you deploy them like any other change.
Does this work with Laravel's native lang files?
Yes. LangSyncer uses Laravel's own localization system, so your templates keep calling __() with the keys you already have. Import your existing PHP and JSON lang files, and export them back whenever you want. Laravel 10+ and PHP 8.2+.
What happens to my translations if I cancel?
Your account drops to the free tier at the end of the billing period and your translations stay yours. Export them as native Laravel lang files, commit them, and your app runs exactly as it did before you ever installed anything.
Can I let a client or a translator in without giving them everything?
Yes. Access is per project and per role. Someone can be given a single project and the ability to translate in it, and nothing else in your account is visible to them.
How good are the AI translations?
Good enough to be a first draft, which is exactly how they're treated. AI fills in a target language using the surrounding keys as context, and the result stays a draft until a person reviews and publishes it. Nothing an AI wrote reaches your users on its own.
How does the scanner find hardcoded text?
You run php artisan translator:scan in your project. It reads your Blade templates and PHP files and reports text that should have been translatable — headings, buttons, placeholders, alt text, exception messages — and proposes a key for each. You approve the ones you want, then apply them locally and review the diff before committing.
Is there a free plan?
Yes, and it takes a real project rather than a demo one. The paid plan adds a 7-day trial with no card up front, no contract, and cancellation whenever you like.
Laravel only?
For now, yes. The client package is Laravel-native and that's where the product is proven. The platform underneath is framework-agnostic and Symfony and WordPress are on the roadmap, but we would rather say that plainly than imply support that doesn't exist yet.
The next "can you just change one word?" doesn't have to reach you.
Import your lang files, hand the keys to whoever owns the words, and get your afternoons back. Free tier, no card, and your files export back out any time.