- How do I install kongulov/nova-tab-translatable?
- Install it with Composer using composer require kongulov/nova-tab-translatable, then wrap the translatable field array inside your Nova resource's fields() method. There are no migrations, scheduled jobs, or public request paths, and in the common case no publish or asset-build step. Confirm the declared Nova, Laravel, and PHP constraints in composer.json before adopting.
- Which Nova, Laravel, and PHP versions does this package support?
- The package declares its supported version ranges in composer.json, but verify them directly against the repository because the recorded last-release date is future-dated and should be treated as unverified. Nova's field API and asset pipeline have moved across majors, so a small package tracking Nova internals is the most likely breakage point at upgrade time. Any compatibility claim derived from that release metadata is unsubstantiated until confirmed against the actual tags.
- Does nova-tab-translatable require spatie/laravel-translatable?
- It is a presentation-layer wrapper inside Nova's field system rather than a translation engine, so it reads localized content persisted in a shape the package understands, typically spatie/laravel-translatable JSON columns. Whether it hard-pins spatie/laravel-translatable or also tolerates Nova's native translatable fields and plain JSON columns should be checked in composer.json. If your localization storage does not match, the package is irrelevant and evaluation ends there.
- How do I group translatable fields into locale tabs in a Laravel Nova resource?
- You wrap your existing field array in the package's translatable-tabs construct within a single Nova resource, which regroups duplicated per-locale inputs into one tab per locale. The data contract is unchanged, so routing, persistence, validation rules, queues, and domain logic are untouched. Realistic pilot effort is half a day to a day for a developer who already knows Nova.
- How are validation errors surfaced when the field is inside an inactive locale tab?
- This is a real UX-level correctness risk: a validation error on a field living in a non-active tab can be invisible to editors, letting incomplete or invalid localized content save silently. Treat it as a data-quality failure mode with business consequences rather than a crash, and surface the behavior to content owners instead of burying it in a ticket. Test it explicitly during the pilot, because it is not something the package can be assumed to solve.
- What is the fallback-locale rendering behavior when a translation is missing or empty?
- Fallback behavior for missing or empty translations is one of the key questions to verify before adoption, since the package renders whatever your localized data contains. Locale drift between config/app.php, the model's $translatable array, and what the package renders as tabs is the most likely source of confusing wrong-tabs reports. Confirm the actual rendering against your own fallback configuration rather than assuming.
- Is kongulov/nova-tab-translatable safe to depend on in production?
- Risk here is dominated by supply chain and version coupling rather than code complexity: roughly 84 stars, zero dependents, a single maintainer, and an MIT license. Low dependents is not evidence of poor quality, but it means you are among the first to hit edge cases with no community backstop and no vendor SLA. Give Nova major-version breakage a named owner, and note that rollback is a one-line change plus the lockfile.
- Are Vue assets pre-built, or does it add an npm build step to deployment?
- In the common case adoption needs no publish or asset-build step, but whether Vue assets ship pre-compiled or drag an npm build into your pipeline is an administrative unknown worth confirming. Check the same way whether a test suite exists that you can run. Resolve both before the package becomes part of your deployment path.
- How do I control which locales appear as tabs?
- Tabs follow your application's configured locales and the model's $translatable array, so adding or removing a language is a configuration change rather than a code change inside the package. Mismatches between config/app.php, the $translatable array, and what the package renders are the usual cause of wrong tabs appearing. Keep those three in sync and the tab list stays predictable.
- Should I use nova-tab-translatable or build the tab grouping myself?
- Evidence suggests reproducing the behavior in-house is roughly 200 lines and one to three engineer-days, which reframes the decision as an efficiency trade rather than a build-vs-buy on product differentiation. If you already run Nova and store translations in readable JSON columns, scope is cheap: a handful of fields() methods plus the lockfile. If either precondition fails, the package is irrelevant and evaluation ends there.