Laravel Nova Lang Laravel Package

Getting Started

This package is not really code you use — it's a bundle of translation JSON files for Nova's own UI strings. The entire integration is three steps:

composer require coderello/laravel-nova-lang
php artisan vendor:publish --tag=laravel-nova-lang
php artisan config:clear

Then set the locale in config/app.php:

'locale' => 'es', // must match a published filename exactly

Where to look first: after publishing, confirm where the files landed. On Laravel 8 / Nova 3 that's resources/lang/vendor/nova/{locale}.json; on Laravel 9+ / Nova 4 it's lang/vendor/nova/{locale}.json. If the tag name isn't recognized (it has changed between releases), run php artisan vendor:publish with no arguments and pick the coderello/laravel-nova-lang provider from the interactive list. php artisan vendor:publish --provider="Coderello\LaravelNovaLang\LaravelNovaLangServiceProvider" is the reliable fallback.

Read the filename, don't guess it. Release notes and READMEs for this package are inconsistent about regional separators — the 2.0.2 notes announce zh-TW and zh-CN with hyphens while the files themselves have historically used underscores (zh_TW, zh_CN, pt_BR). Always ls lang/vendor/nova and copy the literal filename into config/app.php.

First use case: a single-locale admin panel. You have a Spanish-speaking ops team, Nova is in English, and you don't want to hand-translate ~600 strings. Install, set 'locale' => 'es', log in, done. Verify by hitting the login screen and the resource index — those two pages exercise most of the keys.

Pin the version. Since this is pure data, a composer update silently changes what your admin panel says. "coderello/laravel-nova-lang": "2.0.*" plus committed JSON keeps output deterministic.

Implementation Patterns

Single-locale app (the 90% case). Publish everything once, commit the JSON files, set config/app.php, deploy. There's no runtime service provider logic to worry about — the files are inert data that Nova reads natively.

Trim what you ship. Publishing drops 40+ files into your repo. If you only need es and en, delete the rest. It keeps diffs readable and makes it obvious to the next developer which locales are actually supported. If you do plan to add locales later, keep them — they're a few KB each.

Per-user locale switching. The package doesn't give you a language switcher; it only supplies the files. Pair it with a locale column on users and a middleware that runs before Nova's routes:

public function handle($request, Closure $next)
{
    if ($request->user()?->locale) {
        App::setLocale($request->user()->locale);
    }
    return $next($request);
}

Register it in the nova middleware group so it also applies to Nova's API routes, not just the SPA shell. Validate the incoming value against the actual published filenames rather than trusting user input, since a bad code fails silently to English.

Overriding individual strings. Because the files are JSON keyed by the original English string, "editing a translation" means editing the value for an English key. This is also how you handle house style — e.g. translating "Delete" as "Archivar" if your domain says so. Keep a short comment in your team docs listing which strings you've deliberately deviated on, otherwise the next --force publish silently reverts them.

Keeping it current. This is a moving target: Nova adds UI strings with each major/minor release, and the package plays catch-up in content-only releases like 2.0.2 (which refreshed en against the latest Nova, plus de, fr, es, ru, nl). Upgrading Nova and the package together, then git diff on the published files, is the cheapest way to spot which keys changed. Commit the JSON so deploy environments get a deterministic result rather than depending on a publish step running at deploy time (which would also need write access to lang/).

Partial upgrades are fine. If you only care about es, you can re-publish that one file and ignore the rest — the files are independent. Just remember the en file is the fallback surface for untranslated keys, so refreshing en alone changes nothing user-visible for a Spanish panel.

Pairing with your own tooling. Custom Nova tools, cards, and fields ship their own lang/vendor/{tool} files — this package doesn't touch those. If you're building a fully localized admin, treat these files as the third-party baseline and your own packages as the delta.

Gotchas and Tips

• Locale codes must match filenames byte-for-byte. Check ls lang/vendor/nova before configuring. Regional variants exist for Portuguese, Chinese (both scripts), and others; the separator convention (pt_BR vs pt-BR) is not documented consistently across the package's release notes, so trust the filesystem, not the changelog. A mismatched code falls back to English with no warning or log entry.
• --force clobbers your edits. vendor:publish refuses to overwrite by default; when you add --force during an upgrade you lose every hand-tuned string. Diff or back up first — and prefer copying just the files you want refreshed rather than force-publishing the whole set.
• Run config:clear/config:cache after changing locale. With a cached config, edits to config/app.php appear to do nothing — a classic 20-minute debugging detour.
• Missing keys fall back to the English key text, not to en.json. Since keys are the English strings, an untranslated string renders as readable English rather than a nova.something token. That's graceful, but it means "is this fully translated?" requires scanning the UI, not the file. For a quick check: grep -c '":' file.json and compare value-vs-key equality.
• en.json is a real dependency, not a formality. 2.0.2 regenerated en from the latest Nova, which means it's the file that defines which keys are even expected. If you deleted en.json because "we're a Spanish shop," untranslated keys still render correctly — but you lose the reference copy you'd diff against to spot newly added Nova strings after an upgrade. Keep it.
• php artisan nova:publish may re-drop Nova's own en.json. It shouldn't touch other locales, but if your English strings suddenly look stock after a Nova upgrade, that's the culprit. Keep this package's output in a separate commit so it's easy to see.
• JSON validity and encoding. These files are UTF-8; a stray BOM (easy to introduce with a Windows editor) makes json_decode fail and Nova renders raw keys everywhere. If the whole panel reverts to English keys at once, validate the file first.
• RTL languages exist (ar, fa, he) but Nova's CSS is LTR-first. Translations are correct, layout isn't. Expect to add custom CSS if RTL is a real requirement.
• Translations vary in freshness and quality, and only some move per release. 2.0.2 touched de, fr, es, ru, nl, zh-TW, zh-CN and en, added lv, and left the remaining dozens untouched. Treat any given locale as a starting point, not a guarantee — spot-check the flows your users actually touch, and file a PR upstream when you find gaps. That's cheaper than maintaining a fork.
• The "development commands" in the changelog are maintainer tooling. 2.0.2's bugfixes there don't affect installed apps; you can ignore them unless you're contributing locale files back.
• No extension points, no config, no API. If you find yourself wanting to hook into this package, you're solving the wrong problem — you want Nova's own localization, a middleware, or your own tool's lang files.