Filament Translatable Strings Laravel Package

Product Decisions This Supports

• Localization roadmap and i18n strategy: This package gives non-technical stakeholders (content, marketing, support) a Filament-native admin surface for reviewing and editing translatable strings, which turns "we should support more locales" from an engineering backlog item into a product decision you can ship incrementally, locale by locale.
• Build vs. buy for translation tooling: Rather than building an in-app translation editor or paying for a third-party TMS (Lokalise, Crowdin, Phrase) on day one, this package is a low-cost, self-hosted middle path. It is the right evaluation candidate when you want translators working inside the existing admin panel instead of a separate SaaS.
• Editorial workflow and content ownership: Enables a decision to move translation content ownership out of PRs and into the admin UI, reducing engineering toil per copy change and shortening the loop between legal/marketing approval and release.
• Scope decisions per surface: Useful for deciding which parts of the product get in-app translation management (marketing pages, CMS-driven content, emails) versus which stay in code (validation messages, tightly coupled domain strings).
• Upgrade planning as a product risk item: v3.0.0 is a breaking major driven by dependency jumps (wotz/filament-translatable-tabs v3 and maatwebsite/excel v4). If you are on Filament v3, this release is a forcing function: it likely pulls your admin stack to Filament v4, which is a cross-team migration, not a routine patch. That belongs in the roadmap as a scheduled dependency-currency initiative, budgeted with QA time on the admin panel and any Excel import/export paths.
• Vendor and dependency risk posture: The change log shows an active dependabot and a coordinated PR to track upstream majors — modest evidence of maintenance hygiene, which supports (but does not by itself justify) a "keep it, keep it current" decision.

When to Consider This Package

Adopt when:

• You are on Filament (v4, given the v3 tabs dependency) and want translation editing to live in the same panel your team already uses, avoiding a new tool and a new login.
• Your translatable content is file/short-key based (Laravel lang files or a strings table) and volume is in the hundreds-to-low-thousands of strings — enough that manual editing hurts, not so much that you need translator memory, glossary enforcement, or per-locale vendor workflows.
• You have a small number of locales and a non-engineer (or a PM-adjacent content owner) who will actually use the UI. The value is realized only if someone other than developers edits strings.
• You want an Excel round-trip: the maatwebsite/excel v4 dependency suggests bulk export/import for handing spreadsheets to external translators and pulling results back. That is the single strongest argument for this package over hand-rolled tooling.
• You accept the upgrade cadence implied by tracking upstream majors — plan a migration spike before committing, not after.

Look elsewhere when:

• You are on Filament v3 and cannot move to v4 in this cycle. v3.0.0 is a hard major; stay pinned to v2.1.2 and treat this as blocked, not urgent.
• You need real TMS capabilities: translation memory, glossaries, per-locale reviewer sign-off, automated pseudo-localization, screenshot context for translators, or continuous sync with a vendor. A Filament plugin will not replace Crowdin or Phrase at scale, and trying to stretch it there costs more than the license.
• Your strings are few and stable (under ~50, one or two locales). The admin surface and upgrade burden exceed the benefit; a lang file plus a PR template is cheaper.
• String content is security- or compliance-sensitive with audit requirements (who changed what, when, with approval gates). Verify whether change history and permissions meet your controls before piloting — the release notes give no evidence either way.
• You need guaranteed vendor support/SLA. This is a small, single-maintainer-adjacent package; no support contract is implied.
• Bulk Excel import/export is central to your workflow and you already run maatwebsite/excel v3 elsewhere — v4 is itself a breaking upgrade and this package now shares that constraint.

How to Pitch It (Stakeholders)

For executives (one paragraph): Localization is frequently gated not by translation cost but by the friction of getting strings into and out of the product. This package lets the people who own our copy edit translations directly inside the admin panel we already run, with spreadsheet export/import for external translators — so we can add locales without adding headcount, a new SaaS subscription, or an engineering ticket per string. The trade-off is timing: the new v3.0.0 is a breaking release that rides on a Filament major upgrade, so the ask is a scoped migration slot with QA on the admin panel, not an immediate swap. Recommendation: pilot on one secondary locale behind our existing process, measure time-to-publish for a copy change, and decide on full adoption at the next planning cycle.

For engineering (bullet summary):

• v3.0.0 is a breaking major. Two upstream jumps: wotz/filament-translatable-tabs → v3 and maatwebsite/excel → v4. Treat as an upgrade project; composer require will not be a drop-in from v2.1.2.
• Expect coupling to Filament v4 via the tabs upgrade. Confirm the Filament version matrix and lockfile resolution before estimating; this is the dominant cost, not the plugin itself.
• Excel v4 is a second breaking surface. Any existing import/export code (ours or the package's call sites) needs review for API changes, and if we use maatwebsite/excel v3 elsewhere in the app, we now have a shared-major constraint to reconcile.
• Positive signal: dependabot activity plus a deliberate dependency-upgrade PR indicates maintained upstream tracking.
• Pilot plan: spike on a branch against a staging copy, exercise export → external translation → import round-trip with a realistic payload, and check authorization/permissions on the editing screen. Pin v2.1.2 on main until the spike is green.
• Open questions to close in the spike: change history/audit of edits, permission granularity per locale, behavior with large string counts, and whether the package's Filament v4 requirement matches our panel upgrade timeline. The release notes answer none of these — do not infer them.