Filament Astrotomic Laravel Package

Product Decisions This Supports

• Multi-market / multi-language roadmap go/no-go. If localized content is on the roadmap (new country launch, localized storefront, regional landing pages), this package is the cheapest path to a working translation UI inside the admin panel you already have — it turns "we need an i18n admin surface" from a multi-sprint feature into an integration task.
• Build vs. buy for the translation editing surface. Building locale tabs, per-locale field validation, "required in primary locale only" rules, save/sync logic, and delete cleanup against astrotomic/laravel-translatable is roughly 1–2 sprints of engineering plus ongoing maintenance. This package is a thin, MIT-licensed adapter that removes that work. Buy (adopt) unless the UI requirements are genuinely custom.
• Scoping a CMS/content-ops capability. Supports the decision to let marketing/ops staff author localized product descriptions, category names, page copy, and SEO fields without engineer involvement — a common driver of admin-panel investment.
• Choosing a translation data model. This is an architecture-adjacent product decision: it only fits if the product has already standardised on Astrotomic's translation-table approach. If the team is still undecided between Astrotomic, Spatie Translatable, or JSON-column storage, treat this package as a signal that the Astrotomic path has a ready-made Filament UI, and weigh that as a modest tiebreaker — not as the deciding factor.
• Deciding where translation happens. Supports the decision to keep translation authoring in-house in the admin panel versus pushing content into a TMS (Crowdin, Lokalise, Weblate). This package implies in-house authoring by internal staff; it is not a substitute for an external translator workflow with review states and translation memory.
• De-risking an existing Filament admin investment. For teams already on Filament, it extends the panel's value into a new capability without a second admin tool or a new vendor contract.

When to Consider This Package

Adopt when most of these are true:

• Models already use astrotomic/laravel-translatable (this is a hard prerequisite, not a preference — it does not work with Spatie's or JSON-column translations).
• The admin surface is Filament v3/v4 and the team intends to stay there.
• Locale count is modest (roughly 2–6) and translation is performed by internal staff, not an external agency.
• Content volume is human-scale; nobody needs bulk import/export, translation memory, or approval workflows.
• Engineering is time-constrained and would otherwise hand-roll locale tabs.
• The team is comfortable owning a small, forkable dependency: MIT licence, small surface area, so a fork is a realistic fallback if upstream goes quiet.

Look elsewhere or build in-house when:

• The data layer is Spatie-based. Stop here; evaluate a Spatie-oriented Filament translation plugin instead.
• Vendor-risk tolerance is low. 8 stars, 0 dependents, and a single maintainer is a genuine bus-factor and abandonment risk. For a revenue-critical admin panel, either fork it internally on adoption or budget the maintenance yourself. Do not adopt it into a regulated or SLA-bound product without a fork plan.
• Translations are a workflow, not a form. External translators, review/approval states, per-locale permissions, or translation memory mean you need a TMS integration, not a form plugin.
• High locale count (10+). Tab-per-locale UIs degrade badly; a grid or TMS-driven model wins.
• You need published support guarantees. No commercial backing, no dependents, and low adoption mean no one to escalate to — plan for self-support.
• Requirements are only "one extra language, one field." A hand-rolled Repeater may be simpler than any dependency; adding a package for two fields is negative value.

Due diligence before committing: pin the version explicitly, confirm Filament v3/v4 compatibility against your installed version, write one integration test covering create/update/delete across locales, and record a named internal owner for the fork.

How to Pitch It (Stakeholders)

For executives — one paragraph: Localizing the admin panel so staff can enter content in every target language is currently unbuilt work. This is a small, free (MIT) plugin that adds that capability to the Filament admin we already run, on top of the translation library our models already use. It converts roughly 1–2 sprints of custom engineering into a short integration task, which is the difference between shipping a localized launch this quarter and deferring it. The trade-off is honest: it's a young package with a single maintainer and almost no adoption, so we treat it as a replaceable component — we pin the version, cover it with a test, and can fork it internally at low cost because the licence permits it and the scope is narrow. Recommendation: adopt for the multi-language launch, with a fork contingency, and revisit if we ever need external translator workflows or more than a handful of locales, where a translation management system would be the right spend.

For engineering — the practical case: This is a thin Filament adapter over astrotomic/laravel-translatable that handles locale tabs, per-locale field state, and sync — the repetitive glue you'd otherwise write and re-write for every translatable resource. It's MIT, small, and easy to read, so auditing it is cheap. Caveats to plan around: verify compatibility with our Filament major version before committing, pin the release, and add a smoke test around save/delete so an upstream break is caught by CI rather than by content editors. Because it's a thin layer over a stable library, the exit cost is low — worst case we vendor a fork and maintain it ourselves, which is still cheaper than building the UI from scratch.

For product/ops stakeholders — what changes for them: Content editors gain language tabs on every translatable resource, so localized copy can be authored and corrected without engineering tickets. Scope it honestly: it improves authoring of existing content fields; it does not add review workflows, bulk translation import, or third-party translator access.