Laravel Larex is a translation-string extractor: you keep writing normal __('...') / @lang('...') calls in Blade and PHP, and the package scans your code to make sure every string exists as a key in your JSON translation files, creating the missing ones for you.
Install and publish config (this is a dev-time tool — the artisan commands are what you use, so --dev is usually appropriate; if the package ends up in production and the command is missing after a --no-dev deploy, that's expected):
composer require --dev lukasss93/laravel-larex
php artisan vendor:publish --tag=larex-config # check the prompt list if the tag differs in your version
Look first at config/larex.php. That file is the whole package: it tells Larex where to scan for translation calls and which file backs each locale. The shape is roughly:
return [
// Directories/files scanned for __('...'), @lang(...), trans(...)
'source' => [
resource_path('views'),
app_path(),
],
// One entry per locale: where the strings live and in what format
'translations' => [
'en' => ['path' => lang_path('en.json'), 'format' => 'json'],
'it' => ['path' => lang_path('it.json'), 'format' => 'json'],
],
// Globs/dirs to skip — always add vendor, node_modules, public/build
'exclude' => [
'vendor',
'node_modules',
],
];
First use case — five minutes in. Take an app that already calls __('Checkout summary') in a Blade view but has an empty (or missing) lang/en.json:
touch lang/en.json && echo '{}' > lang/en.json # if it doesn't exist yet
php artisan larex:extract
git diff lang/en.json
You should see "Checkout summary": "Checkout summary" appear. From then on, en.json is your source of truth for source strings and you hand the other locale files to translators. Check php artisan list larex and php artisan larex:extract --help first — the flag set has grown across 4.x and the help output is more reliable than any blog post.
JSON-key style, not short-key style. Larex is designed around the "the English sentence is the key" convention (lang/en.json), which is why extraction can work at all. If your app uses __('messages.welcome') with lang/en/messages.php, extraction is largely a no-op for those strings — plan to keep Larex scoped to your JSON layer, or to migrate as you touch screens.
Extract → translate → ship, as a loop. The day-to-day rhythm:
php artisan larex:extract # pull new/changed strings into every configured locale
# send lang/{it,de,fr}.json to translators / your TMS
php artisan larex:format # normalise + sort so the diff is reviewable
CI guard against untranslated code. The highest-value pattern is failing the build when someone adds a __() call without extracting:
php artisan larex:extract
git diff --exit-code lang/ || (echo "Run 'php artisan larex:extract' and commit the result"; exit 1)
Wire this into a composer script ("lint:lang": "...") so it runs alongside Pint/PHPStan, and into a pre-commit hook if you want it before review rather than after.
Scaffolding a new locale. Add the file and the config entry, then extract once — you get a complete key set with English values as placeholders, which is exactly what a translator wants to receive:
echo '{}' > lang/it.json
# add the 'it' entry to config/larex.php
php artisan config:clear
php artisan larex:extract
Use the finder when translating. When a translator (or a reviewer) asks "where is this string actually used?", jump to it instead of grepping the repo by hand:
php artisan larex:find "Checkout summary"
Round-trip with external translation files. For one-off imports/exports of a translator's JSON, use the import command rather than hand-merging — it keeps the file shape identical to what extract produces, so subsequent extract runs don't produce spurious diffs. Combine with larex:format afterwards.
Keep it out of the request path. Nothing here needs to run in production — no middleware, no runtime lookup. Treat the package as a build tool that happens to live in vendor/.
Static analysis only. Dynamic keys are invisible to the extractor:
{{ __('Hello :name', ['name' => $user->name]) }} {{-- extracted ✅ --}}
{{ __('Hello ' . $user->name) }} {{-- NOT extracted ❌ --}}
{{ __($label) }} {{-- NOT extracted ❌ --}}
If you need variable content, keep the key literal and use :placeholders. Anything else silently ships untranslated.
Placeholders and pluralisation must match exactly. trans_choice('apple|apples', $n) becomes the JSON key apple|apples — pipes and all. A stray space around the pipe means translators get a key that never resolves. Same for :count, :name — a typo in one locale is a runtime "translation missing" you'll only spot in QA.
Sort before you commit, always. JSON translation files are pure merge-conflict bait: two branches each append a key at the bottom, and you get a conflict on every branch afterwards. larex:format (sort keys, consistent indent) turns those into clean three-way merges. Make it part of the same hook as extract.
Quotes and apostrophes. __("Don't delete this") produces a JSON value that must be escaped. Let the tool write the file — hand-editing JSON with apostrophes is where corrupted locale files come from. If you see \u0027 littering your diffs, that's the encoder, not a bug; check whether your version exposes an unescaped-unicode option before doing post-processing yourself.
Path drift between Laravel versions. Laravel 8-era apps use resources/lang/; 9+ uses lang_path(). If Larex finds nothing, this is the first thing to check — a copied config from an old project will point at a directory that no longer exists, and the command happily reports success with zero changes.
Exclude aggressively. Scanning vendor/ or node_modules/ will pull in hundreds of unrelated __() calls and pollute your translation file with strings from packages. Add them to exclude, and re-check after any big dependency bump.
Config cache. config/larex.php changes are invisible until php artisan config:clear if you've cached config locally. This bites during the "add a new locale" step and looks like the package ignoring your config.
Laravel 13 support landed in v4.7.0. The only change in this release is added Laravel 13 compatibility; there are no breaking changes, no deprecations, and no new options between 4.6 and 4.7. Upgrade is a plain composer update lukasss93/laravel-larex — pin ^4.7 if you're moving the app to Laravel 13, otherwise stay on whatever 4.x you're already on. Because this is a dev-time extractor with no runtime surface, a failed upgrade manifests as a missing/erroring artisan command rather than broken pages, which is a good place to be.
Extension points are limited by design. There's no event system or driver interface worth building on; the supported customisation is the config (source paths, per-locale file path/format, excludes) plus the format step. If you need keys pulled from somewhere other than PHP/Blade source — a CMS, a database — write your own command that writes the JSON file, and let Larex handle only the static code scan.
Commit before a first bulk extract. On a legacy app the first extract can touch thousands of lines. Run it on a clean tree, in its own commit, so you can review the output as a diff instead of discovering it buried in a feature branch.
How can I help you explore Laravel packages today?