Filament Localization Laravel Package

Product Decisions This Supports

• Localization epic sizing. The core value is converting a manual, per-field chore (hundreds of TextInput, TextColumn, Section, action labels across every resource, page, and relation manager) into one reviewable command. A PM can use a --dry-run spike to produce a real estimate — "N files touched, M keys generated" — instead of guessing at a multi-sprint i18n backlog.
• Build vs. buy for internal tooling. Nobody should hand-roll a Filament resource scanner. This is a codegen/refactor utility, not a platform. The decision it informs is narrow: adopt, fork, or do the mechanical work manually once and never look back.
• Roadmap gating on stack upgrades. The package hard-requires PHP 8.3+, Laravel 12/13, Filament 5, Livewire 4. That makes it a forcing function: admin-panel localization is effectively blocked behind the framework upgrade. Sequence accordingly, or accept that v1.x (Filament 4) is the fallback and carries the maintenance tail.
• Scope-boundary definition. It localizes admin UI chrome only. It does not translate database content (posts, product names), which is a different package (spatie/laravel-translatable plugin), and it does not ship a locale switcher (it delegates that to a third package). This clarity is useful for splitting one giant "make the app multilingual" ask into three independently-scoped decisions with different owners and risks.
• Vendor and data-egress risk. The optional DeepL path sends admin UI strings — sometimes including field names, hints, and internal terminology — to a third-party API. That is a procurement/compliance decision for regulated or air-gapped environments, and it's decidable independently of the codegen feature.
• Ongoing drift maintenance. "Smart detection" of missing and untranslated keys implies the tool can be re-run as a CI/drift check after features ship, not just at kickoff. That reframes localization from a project to a low-cost recurring chore — a materially different resourcing ask.

When to Consider This Package

Good fit:

• A Filament 5 / Laravel 12+ panel that is going multi-locale for the first time, or retrofitting a large existing panel where manual key extraction is genuinely expensive.
• A team that can review a large diff: --dry-run, --panel scoping, automatic backups, and git commits with easy revert are the right safety primitives, but they only pay off if someone actually reads the output.
• Teams comfortable owning the tool — 11 stars, 0 dependents, single maintainer, MIT. Budget for a fork and version pin from day one rather than assuming upstream responsiveness.
• Where DeepL is acceptable, or where the team will translate the generated files manually/by agency.

Look elsewhere when:

• You need to translate content (model attributes, CMS records, user-generated text) — wrong tool entirely.
• You're on Filament v3/v4, PHP <8.3, or Laravel 11 — the compatibility matrix excludes you, and v1.x is a deprecated branch.
• The panel has a few dozen strings; manual __() calls are cheaper than adopting, configuring, and auditing a dependency.
• You need vendor support, an SLA, or evidence of production use at scale. Zero dependents means zero public proof points.
• Strings can't leave your infrastructure, or you need nuanced locale behavior (pluralization, RTL, per-tenant overrides) beyond flat key/value files.
• Your codebase has heavily customized or dynamic Filament components — scanner coverage of the documented component list is broad but not a guarantee against your hand-written subclasses.

Recommendation: timeboxed spike, not adoption. Run filament:localize --dry-run against the single largest panel, inspect the diff for correctness and readability, and compare a translated slice with the manual baseline. Gate the real decision on that diff quality and on the stack-upgrade timeline.

How to Pitch It (Stakeholders)

Executives (one paragraph): We're evaluating a small, MIT-licensed open-source tool that mechanically converts hardcoded admin-panel labels into translatable keys, optionally auto-translating them. It targets the tedious 80% of localization work — the part that is high-volume, low-judgment, and easy to underestimate. It's reversible by design (dry-run mode, backups, git commits), free, and doesn't lock us in. The counterweight is maturity: it's a new project with a single maintainer and essentially no public adoption, built only for our newest framework versions. So the ask is a few days of engineering to validate on one panel — not a commitment to a vendor or a platform. If the generated code is clean, it converts a multi-sprint localization epic into a short cleanup pass plus translation review; if not, we lose a spike and do it manually.

Engineering: This is an automated refactor, not a runtime dependency. It rewrites resource and page files — nulls out static labels and generates getX() accessors returning __() keys — and emits structured lang/ files using a configurable layout (panel-based recommended; flat and nested available). Safety rails we'd rely on: --dry-run, --panel/--locale scoping, --force to overwrite, --no-git for controlled commits, backups, and excluded_panels/excluded_resources config. The DeepL command is isolated and opt-in via DEEPL_API_KEY, with a skip_identical_terms list that sensibly protects acronyms and brand names — and --dry-run there too. What we need from a spike: diff quality on our most complex resource, behavior on any custom components, and whether the generated key namespace survives a second run without churn. Treat it as a forked tool — vendor the config, pin the version, and assume we maintain it.