Filament Tab Translatable Laravel Package

Getting Started

Start by pulling the patch and re-reading the README, which was updated in 2.0.1. The release adds a tabs property and nested untranslatable field support, so the README is the fastest way to see the intended configuration shape before you wire anything into an existing form.

Minimal steps:

1. composer update the package to 2.0.1.
2. Clear cached config/views (php artisan optimize:clear) since the package now ships stricter code and a new property.
3. Open the package config and the README section on tabs; confirm whether tab grouping is opt-in or default for your existing field definitions.
4. Build one small form first: a single translatable field inside a tab, plus one nested untranslatable field. That exercises both new features without committing a large form to the new structure.

First practical use case: a content edit screen where translatable fields (title, body) live in locale tabs, while shared fields (slug, status, publish date) sit nested but untranslated. The 2.0.1 changes target exactly this layout.

Implementation Patterns

Tabbed translatable forms. Use the new tabs property to group translatable fields per locale rather than rendering every locale inline. For day-to-day work this means one tab per configured locale, with the same field set repeated inside each tab. Keep the tab definition close to the field definition so adding a new translatable field automatically appears in every locale tab.

Nested untranslatable fields. 2.0.1 allows untranslatable fields to be nested inside translatable structures. The pattern that works well:

• Put locale-specific fields inside the tab/translation container.
• Put shared fields in a nested block and explicitly mark them untranslatable.
• Verify that shared fields are saved once, not once per locale, when the form submits.

Strict code expectations. The “code strict” change means the package now expects stricter types. In your own integration code:

• Type-hint package classes and your form/data objects.
• Avoid passing null where the package now expects a string/array.
• Run static analysis (phpstan, psalm) or at least php -l across your form classes after upgrading.

Integration tips.

• Wrap the package’s tab/field builder in your own helper if you repeat the same locale tab structure across resources.
• Keep locale lists in config, not hard-coded in each form, so tabs stay in sync with the app’s supported locales.
• If you already have custom tab logic, map your existing tab names to the package’s tabs property rather than running two tab systems side by side.

Gotchas and Tips

• Patch release, but behavior-adjacent. 2.0.1 is a patch, but the new tabs property and nested untranslatable support can change rendering and save behavior. Test one existing form before rolling out across all resources.
• Tab conflicts. If your form already defines tabs, the new tabs property may double-wrap or reorder them. Check the rendered form, not just the saved data.
• Nested untranslatable fields and saving. The most likely bug is a shared field being duplicated per locale or being skipped entirely. Inspect the request payload and the persisted model after submit.
• Strict types surface legacy code. Errors like type mismatches often come from your own form/data classes, not the package. Trace the stack to the first package boundary and check the argument types there.
• Debugging workflow. Clear caches, dump the form schema before render, then dump the validated payload before save. That isolates whether the issue is tab construction or persistence.
• Extension points. Prefer the package’s field/tab configuration over subclassing internals. The README update is the best signal for supported extension points in 2.0.1; avoid relying on undocumented tab internals that may change in 2.0.x patches.