Weave Code
Nova Language Management Laravel Package
crayon/nova-language-management
A Laravel Nova package for managing application languages and translations straight from the Nova admin panel. Add, edit, enable, or disable locales, organize language files, and keep multilingual content in sync without editing config files or using the CLI.
At a glance
Frequently asked questions about Nova Language Management
- What does crayon/nova-language-management actually do?
- It is a Laravel Nova tool that adds a database-backed CRUD surface for managing application languages and translation strings from the Nova admin panel. Instead of editing lang files or running artisan commands, an editor can add, edit, enable, or disable locales at runtime. It only makes sense if your application already runs Nova, which is a paid first-party admin panel. Laravel ships file-based translations, so the package's value is moving editorial control of those strings into a UI.
- How do I install crayon/nova-language-management?
- Install it with Composer from the crayon/nova-language-management package name and then follow the repository README for registration. Like most Nova tools, it will need to be added to the tools() array in your NovaServiceProvider, and the package's migrations must be run to create the languages and translations tables. Confirm the exact service provider and migration steps in the repo before installing, since the README documentation is sparse and the package has not been updated since July 2023.
- Is crayon/nova-language-management compatible with Laravel 11, Laravel 12, and Nova 5?
- Compatibility is unverified: the last tagged release was July 2023, which predates Nova 5 and Laravel 11/12. Check the composer.json constraints on laravel/nova, laravel/framework, and PHP first, and look for a maintained branch. If the constraints block current versions, budget time to fork and update rather than expecting a patch release. A two-day spike against your actual Laravel and Nova versions will settle it quickly.
- Does it replace Laravel's file-based translator with a database loader?
- That is the load-bearing question, and the answer is not clearly documented. For __() to resolve strings from the database, the package must ship a LoaderInterface implementation bound into the container; if it only provides the Nova CRUD screens, you own the loader, fallback chains, pluralization behavior, and caching yourself. Inspect the source for a translation loader and a service provider binding before estimating effort. In practice this is the majority of the integration work, not the installation.
- Is crayon/nova-language-management safe to use in production?
- Treat it with caution: it has roughly 4 GitHub stars, zero dependents, no release since July 2023, and no evidence of production use elsewhere. There is also no documented audit trail, draft/publish workflow, or rollback, so edits go straight to live production strings. A database-backed loader introduces a runtime dependency where a slow query or database outage degrades every rendered page, not just the admin panel. The safer path is to fork it and implement a dual-read strategy with a cached translation map.
- Does it support vendor namespaced translation groups like vendor::file.key?
- This is listed as an open question in the technical evaluation and is not documented. Verify in the source whether the loader and the import path handle namespaced groups, or only application-level lang files and JSON keys. If vendor namespaces are unsupported, exclude them from your importer and let those continue resolving from files. Do not assume parity with Laravel's file loader on fallbacks, pluralization, or JSON keys without testing each case.
- How are translation caches invalidated when a translation is edited?
- The invalidation strategy is undocumented, so you must verify it before relying on it. The recommended approach is to preload the full translation map per locale into Redis or the file cache under a versioned key and invalidate that key on write, rather than querying the database per key at render time. On a multi-server deployment the invalidation must go through a shared cache so every node picks up the change. If the package does not handle this, you will need to build it into your fork.
- Can I export translations back to lang files?
- No export path is documented, and without one, rollback and local development become painful. Plan to build the reverse of your importer so the database can be frozen back into PHP and JSON files for deploys and for developers running the app locally. The importer itself doubles as the rollback artifact, so write it early rather than treating it as an afterthought. This export step is also what lets you avoid a flag day when switching loaders.
- What is the permission model inside Nova, and does it integrate with policies and gates?
- The authorization story is not documented, so assume you will own it. Wrap the tool in a Nova policy or gate scoped to a dedicated translations editor role, and keep it out of the default admin navigation so ordinary admins cannot edit production copy. Governance is a medium risk here: there is no audit trail, no draft and publish workflow, and no rollback beyond your own export. Decide up front who may modify live strings and log those changes yourself if you need traceability.
- What are the alternatives to crayon/nova-language-management?
- Alternatives include a database translation loader such as spatie/laravel-translation-loader paired with your own Nova CRUD screens, a custom-built Nova tool, or keeping translations file-based and managing them through developer workflows. Forking this package can still be cheaper than starting from scratch because the Nova screens and schema already exist, but only if the loader behaves close enough to Laravel's file loader. Whichever route you take, the loader, caching, and export path are where the real effort sits, so evaluate those first.
Weaver
How can I help you explore Laravel packages today?