One Pot Translations Laravel Package

Getting Started

one-pot-translations is a translation-management layer for Laravel: instead of hand-editing lang/{locale}/*.php files across a growing app, you get a single place ("one pot") to see every key, spot what's missing per locale, and edit strings without touching PHP arrays.

Minimal path:

1. composer require mortendhansen/one-pot-translations — package discovery registers the service provider, no manual providers entry needed on Laravel 5.5+.
2. Publish the config and check the tag name in the readme, as tags vary between packages:

   php artisan vendor:publish --provider="MortenDHansen\OnePotTranslations\OnePotTranslationsServiceProvider"
   

3. Confirm your lang/ path and default locale in config/app.php match what the package expects (lang_path() on Laravel 9+, resources/lang on older versions).
4. First real use case: point it at an existing app that already has lang/en plus one partially translated locale (e.g. es), and use it to enumerate the missing keys before writing a single new string.

Look at the config file first, then the package's route/command registration — that tells you whether it's UI-driven, CLI-driven, or both in this version.

Implementation Patterns

Keep it out of production. The most common deployment of this package is as a local-only tool. Gate it in AppServiceProvider or via middleware:

Gate::define('manage-translations', fn ($user) => $user->isAdmin());

…and wrap any routes it registers behind that gate plus an abort_unless(app()->isLocal(), 404) guard. Translation editing surfaces are an easy way to leak unreleased copy.

Treat lang files as source code. The healthy workflow is: add new strings in Blade/PHP → extract → review the diff → commit the lang/ changes in a PR. That keeps translations reviewable and revertible rather than being mutated live in a database.

Scan-then-review, not scan-then-save. If the package can discover hardcoded strings or missing keys, run the scan, inspect the report, and only then persist. Batch-accepting everything tends to fill your files with keys scraped from comments, test fixtures, and dead code.

Pin en as the canonical locale. Translate outward from en (machine-translate or hand-translate), then have a human review. Never let the tool overwrite en from another locale — key drift starts there.

Add a CI guard. A cheap job that fails the build when a referenced key is missing from any locale catches the "shipped a page with trans('foo.bar') rendering as foo.bar" bug before QA does. Wire it to the package's report output if it offers one, or a small custom assertion over lang/ otherwise.

Editorial workflow for teams. One person edits a locale file at a time. Assign locales by owner (es → Ana, de → Ben) so merge conflicts in monolithic arrays stay rare; key reordering from different editors produces noisy diffs otherwise.

Composer script convenience. Add "translations": "@php artisan <package-command>" to composer.json so nobody has to remember the exact command namespace.

Gotchas and Tips

• This assessment reflects the v1.1.x line. v1.1.2 is a patch bump from v1.1.1 with no published notes beyond the compare link, so assume bugfix-only: no new config keys, no migration required, safe to take on ^1.1. If you hit odd behaviour after upgrading, read the actual diff at the changelog URL rather than guessing — patch releases in this line carry no documented surface changes.
• Caches bite first. After any config or lang/ change: php artisan config:clear, view:clear, and cache:clear if the package caches the catalogue. A stale translation cache is the #1 cause of "the tool shows the new string but the app doesn't."
• Nested arrays vs dotted keys. Laravel accepts both lang/en/auth.php returning ['failed' => ...] and flat dotted keys. Mixing them creates keys the package may round-trip incorrectly — pick one convention per file and stick to it.
• Pluralization and trans_choice don't survive naive editors. Strings using | separators or ICU placeholders are easy to mangle in a UI textarea. Spot-check every pluralized string after editing.
• Re-publishing overwrites. vendor:publish --force will clobber your config. Back it up, or diff before forcing.
• Vendor package translations. Third-party lang files under vendor/ aren't yours; confirm whether the package includes them before assuming a key is genuinely missing.
• Watch the diffs. Editors that alphabetize or reformat arrays will produce a 400-line diff for a one-word change. Configure your editor to preserve key order in lang/ files so review stays meaningful.
• Extension point to lean on: the published config is the intended seam — path overrides, locale lists, and any authorization/route toggles live there. Reach for the config before subclassing or patching the package, since patch releases won't preserve internal overrides.