Filament Translation Editor Laravel Package

Product Decisions This Supports

• Localization scope and cost control. The v1.0.6 flags (support vendor packages => false, auto translation => false) are the levers a PM cares about most: they let you decide whether the string catalog extends into third-party dependency code, and whether machine translation is invoked at all. Auto-translation generally implies metered external API calls — making it opt-in is a direct spend and data-egress decision, not just a technical one.
• Compliance and data-boundary decisions. If auto-translation ships enabled by default, user-facing or admin strings can leave your infrastructure without an explicit product decision. An explicit false default is the posture most security/legal reviews will want; treat this release as the moment to document that choice.
• Roadmap risk assessment. This is a patch release on a 1.0.x line. It does not add features or change the integration surface, so it should not move roadmap dates — but "fixing default values" means behavior can change for existing installs that relied on the old defaults. Budget a verification task, not a planning task.
• Build vs. buy signal. A maintained package with a steady patch cadence is a point in favor of buying/adopting over building an in-house translation layer. One patch release is weak evidence on its own; pair it with release history and test coverage before treating maintainer responsiveness as a settled input.
• Use cases unlocked: multi-locale Laravel apps that want vendor package translations available without hand-copying lang files, and teams that want translation automation available in staging but hard-disabled in production and CI.

When to Consider This Package

Adopt when:

• You are on Laravel and have (or are about to have) a genuine multi-locale requirement — not a "someday" localization backlog item.
• You need translation coverage that reaches into vendor packages and don't want to maintain a manual copy/sync process for third-party lang files.
• You want machine translation as an optional capability behind config, so it can be enabled per-environment (staging/local) and left off in production.
• You can absorb a 1.0.x dependency: patch-level churn is expected, and default-value corrections are still landing.

Look elsewhere when:

• You need a full TMS integration, translator-facing review workflows, or approval gates — this reads as a developer-facing config/string utility, not a translation management system.
• You require vendor SLA, security review artifacts, or long-term support guarantees; a 1.0.x package with terse release notes is unlikely to supply them.
• Your app has a very large dependency tree and you need guaranteed scan performance — support vendor packages => false mitigates this, but verify the cost of enabling it before committing.
• The only requirement is static, hand-authored lang files. You don't need this.

Pre-adoption checks (triggered specifically by this release):

• Determine whether "fixing default values" changes rendered output for installs that relied on the previous defaults. This is the one item in the notes with real upgrade risk.
• Confirm the two new flags are documented in the published config file and are actually read at runtime, not just present.
• Verify the package's test coverage around the opt-out paths — a boolean that silently fails to disable vendor scanning or auto-translation is a cost and compliance bug, and it's exactly the kind of path that goes untested.

How to Pitch It (Stakeholders)

To executives: This is a small, actively maintained localization add-on for our Laravel stack. The v1.0.6 release is a stability patch, but it carries one decision worth surfacing: auto-translation and vendor-package scanning are now explicitly configurable and default to off. That means no surprise per-character translation spend, and no application strings leaving our environment unless we deliberately turn it on. It's a low-risk dependency that removes a recurring manual chore from the team, and it is not on the critical path for any roadmap commitment.

To engineering: Pin to v1.0.6 and diff locale output before and after the upgrade — the default-value fix is the only change that can alter existing behavior. Set auto translation to false in production and CI (determinism, no external calls, no cost), and enable it only in staging if we want the capability. Set support vendor packages deliberately: enabling it widens the string catalog and adds scan time proportional to our dependency tree. Add a smoke test asserting both flags actually short-circuit their code paths, since opt-outs that fail open are silent regressions.

Ask: Approve adoption at patch-pinned version, assign one engineer a half-day for the locale diff and flag verification, and revisit the build-vs-buy call once we have two or three more releases of cadence data.