Weave Code
Multilingual Nova Laravel Package
digitalcloud/multilingual-nova
Add multilingual support to Laravel Nova resources with this package, letting you manage translations for multiple languages directly in Nova forms and fields alongside your existing resource setup.
💪 Multilingual Nova (using default nova fields)
Frequently asked questions about Multilingual Nova
- What is digitalcloud/multilingual-nova used for?
- It adds a Laravel Nova form field that renders locale-keyed JSON translation attributes as a tabbed or collapsible editor inside your existing Nova resource forms. The package is purely the admin presentation layer: storage and locale fallback semantics live in the underlying digitalcloud/multilingual package. It only makes sense if you already run Nova as your admin layer and already store translations as locale-keyed JSON on your Eloquent models. It is not a translation delivery engine, a TMS workflow, or a localization strategy on its own.
- How do I install digitalcloud/multilingual-nova?
- Install it with Composer, publish the package config and assets, then add the multilingual field to the Nova resource that holds your translations. Make sure the underlying JSON column is cast to array or json so Nova can read and write the locale keys correctly. Published frontend assets land under public/vendor, so plan to republish them whenever you upgrade. Realistic effort is a few hours to a first working field and a few days to a validated, regression-tested rollout.
- Which Laravel, Nova and PHP versions does this package support?
- There is no published compatibility matrix, so support for current Laravel, Nova and PHP versions is unverified. The last tagged release was 2021-12-21, well before several Nova and Laravel major cycles. Test the field against your exact Nova, Laravel and PHP combination in a staging branch before budgeting the work. Because Nova itself is a paid first-party dependency, an unsupported wrapper on top of it can break on any platform upgrade.
- What changed in v3.0.0 and can I migrate from v2.x?
- v3.0.0 reworked field registration in PR #56, so field names and aliases may have shifted from v2.x. The release notes are dominated by Dependabot frontend bumps and community patches, with no enumerated breaking changes and no migration guide. Inspect the field service provider, the published config keys and the published asset paths before upgrading. If you have existing translation data shapes, verify them against the new field API in a test resource first.
- How does locale fallback work with partial translations?
- Fallback and partial-translation behavior are owned by digitalcloud/multilingual, not by this Nova field. The field only renders whatever locale-keyed JSON the parent package resolves. Confirm the fallback chain matches what your editors expect before adopting, especially for partially translated records. If the semantics do not fit, the fix belongs upstream in the storage layer, not in the field.
- Is digitalcloud/multilingual-nova still maintained?
- Signals are weak: roughly 65 stars, zero dependents on Packagist, and no release since December 2021. There is no stated maintainer commitment, no sunset plan, and no automated compatibility matrix. Treat it as a risk-accepted internal tool rather than a free capability. If you adopt, assign an internal owner who can fork or replace the field.
- Is it safe to use in production?
- The blast radius is limited because the package touches no public request path, exposes no API surface and defines no data model of its own; it is editorial admin UX for internal operators. The real risks are maintenance and Nova upgrade breakage, not code correctness. The dependency list, including node-sass and older elliptic, ini, y18n and lodash bumps, reflects a legacy asset pipeline and historical CVE remediation rather than proof of a current build chain. Budget accordingly and keep it behind your admin authentication.
- How should I test this Nova field before rolling it out?
- There is no upstream CI compatibility matrix you can lean on, so your own coverage has to carry the weight. Write a Nova resource test that mounts the field, saves a multi-locale payload and asserts the JSON written to the column round-trips correctly. Add regression tests for the custom CSS hook, the locale switcher and the translated tool title, since those recently widened the surface area. Also smoke-test locale fallback with a partially translated record.
- What are the alternatives to digitalcloud/multilingual-nova?
- If you are on Nova, the direct alternatives are a small custom Nova field or a plain JSON textarea that edits the same locale-keyed column with no third-party wrapper. If you are not on Nova, or you do not already store translations as locale-keyed JSON, a custom field or a dedicated translation platform is a cheaper and more durable bet than adopting this package. Do not introduce Nova or digitalcloud/multilingual purely to justify using this field.
- What is the exit cost if this package is abandoned?
- Data portability is the easy part: translations are stored as plain JSON on your models, so nothing is locked into the package. The real cost is rebuilding the editor experience, either as a custom Nova field or a simpler JSON textarea, then re-running your regression tests. Confirm the current JSON shape before adopting so a replacement field can read the same column without a data migration.
Weaver
How can I help you explore Laravel packages today?