Weave Code
Nova Translations Loader Laravel Package
optimistdigital/nova-translations-loader
A Laravel Nova package that loads PHP translation files into the Nova front-end, making existing language strings available to Vue components and tools without duplication. It supports multiple locales and lets you localize custom Nova cards, fields, and tools using your app's existing translation f...
Nova Translations Loader bridges your Laravel application’s localization files with Laravel Nova, so Nova’s UI can use the same translations as the rest of your app. It reduces duplicated strings and keeps custom localization out of vendor files, with a lightweight setup in your NovaServiceProvider.
- Loads Laravel language files into Nova
- Keeps app and Nova translations aligned
- Simple service-provider integration
- Avoids editing vendor translations
- Works with Laravel’s standard locale structure
Frequently asked questions about Nova Translations Loader
- What does optimistdigital/nova-translations-loader actually do?
- It registers your existing Laravel PHP translation files so Laravel Nova's Vue front-end can resolve them at render time. Instead of duplicating strings into vendor files, you keep one set of language files under resources/lang and let both your app and Nova use them. It is a small service provider plus a loader class, not a translation management platform or a runtime i18n layer. Typical use is localizing custom Nova cards, fields, tools and resources with your app's own strings.
- How do I install nova-translations-loader in a Laravel Nova app?
- Install it with Composer as a hard require in the app or package that needs it, then publish the config so you can define scanned paths and namespaces. Add a single NovaTranslationsLoader::loadTranslations(...) call in each package's service provider boot() method, or from your NovaServiceProvider. Keep it in require rather than require-dev, because the admin UI renders raw keys without it.
- Which Laravel and Nova versions does it support?
- Version 5.0.3 is explicitly a Nova 5 compatibility patch, which means the package line is pinned to a Nova major. Whether the 5.0.x line still supports Nova 4 for environments mid-upgrade is an open question that should be confirmed against the repository rather than assumed. Verify your resolved PHP, Laravel and laravel/nova constraints with composer why-not optimistdigital/nova-translations-loader before rolling it out to every environment, including CI and queue workers.
- How do I use it to translate a custom Nova card, field or tool?
- Name the translation file after the package handle, following Laravel's convention of resources/lang/{locale}/my-tool.php, and register that namespace through the loader's config. Nova's front-end then resolves the namespaced keys, such as my-tool::title, inside your Vue components. Your tool keeps its strings in the same files as the rest of the application, so there is no second copy to maintain.
- Does nova-translations-loader support multiple locales?
- Yes. It follows Laravel's standard locale structure of resources/lang/{locale}/{namespace}.php and registers those namespaces so Nova can resolve them per locale. Switching the locale in your app therefore switches the Nova UI strings as well, provided each locale has the corresponding files. Confirm this in a running panel with more than one locale before relying on it.
- Why are my translation keys showing up untranslated in Nova?
- The loader fails silently: nothing throws when a namespace is not registered, so you simply see my-tool::title rendered in the admin UI. The usual causes are a missing or unpublished config entry, a wrong namespace or path, or two competing registrations where whichever runs last wins. Prove the strings reach the browser in a running panel with at least two locales, because no automated test in this package will catch it for you.
- Will it conflict with my existing loadTranslationsFrom() or addNamespace() calls?
- It can. If you register the same namespace both manually and through the loader, the last registration wins and strings can disappear with no error at all. The migration step is deleting the old registration boilerplate, not adding the loader alongside it. Inventory your existing manual namespace registrations first so you do not double-register.
- Do I need this package if I only maintain one or two Nova packages?
- Probably not. With one or two packages, a short loop or a loadTranslationsFrom() call in a base service provider does the same work with zero third-party surface. The dependency earns its place only when several Nova tools, cards, fields or resources each ship their own strings and would otherwise repeat the same registration block. Below three or four packages, skip it.
- Is it safe for production, and who maintains it?
- It is a narrow single-purpose utility with a single-maintainer lineage from optimistdigital to outl1ne, a modest star count and no vendor SLA, so treat it as a pinned-and-monitored dependency rather than a platform commitment. Pin the exact version, record it next to your Nova version per environment, and accept that forking is the exit, which is an hours-scale job given the code size. The blast radius is limited to internal, employee-facing admin tooling, so a failure degrades back-office usability rather than customer experience.
- How do I test that Nova actually receives the translations?
- Load a panel that has more than one locale and confirm your custom tool, card or field renders translated strings instead of namespaced keys. Switch locale and check that the strings change accordingly. Since the package throws nothing on failure, this manual check is the real verification step. Running it in CI or staging against your pinned Composer constraints catches most upgrade surprises.
Weaver
How can I help you explore Laravel packages today?