Filament Translation Editor Laravel Package

Getting Started

This release (v1.0.6) is a defaults/behaviour fix rather than a new feature, so the fastest path is to confirm what your app currently resolves for the affected config flags before writing any new code.

1. Install/upgrade as usual — composer require <vendor>/<package> (or composer update <vendor>/<package> if already installed).
2. Publish and diff the config — php artisan vendor:publish --tag=<package>-config into a scratch directory first, then diff against your existing config/<package>.php. The release explicitly changes default values, so your published config is the single most important file to review.
3. Clear cached config — php artisan config:clear (and config:cache again in production). Default-value changes are invisible while a stale bootstrap/cache/config.php is in place — this is the number one cause of "the upgrade didn't do anything".
4. First use case to verify — run the package's primary command/entry point against a small subset of your app (one locale, one namespace) and confirm that vendor packages are excluded and auto-translation is off unless you opted in.

Where to look first: the package's config/<package>.php, its README changelog section for v1.0.6, and any service provider mergeConfigFrom / register calls that read these flags. If the package ships an Install or Publish command, run it and inspect the generated file rather than assuming the new defaults.

Implementation Patterns

Treat the two flags as explicit opt-ins. Post-1.0.6 the safe posture is "off by default":

• Vendor package support defaults to false — only enable it if you genuinely need translations/behaviour from vendor/ packages. Scope it narrowly (specific package names) rather than flipping a global boolean where the package allows a list.
• Auto translation defaults to false — drive translation through explicit calls or an artisan command in CI/deploy, not implicitly at request time. This keeps production predictable and avoids surprise external API calls.

Config-first, code-second. Set the flags in config/<package>.php and in environment variables, not by mutating them at runtime:

// config/<package>.php
return [
    'vendor_packages' => env('PKG_VENDOR_PACKAGES', false),
    'auto_translate'  => env('PKG_AUTO_TRANSLATE', false),
];

Environment-driven rollout. Ship PKG_VENDOR_PACKAGES=false and PKG_AUTO_TRANSLATE=false to all environments first, then enable per-environment (local/staging only) and observe. This makes the new defaults a no-op for existing deployments and turns the feature on deliberately.

Feature-test the flags, not the package. Write a small test asserting the resolved config and the resulting behaviour:

it('excludes vendor packages by default', function () {
    config()->set('<package>.vendor_packages', false);
    // assert the service/command output omits vendor-sourced entries
});

Deploy-pipeline pattern. If your deploy relies on auto translation, move it into an explicit step (artisan command / queued job) so it runs once, visibly, and can be retried — rather than depending on an implicit default that just changed under you.

Gotchas and Tips

• The breaking change is silent. Flipping defaults to false won't throw — it will simply stop doing work you may have been relying on. Grep your codebase and env files for anything that assumed vendor support or auto translation was on. Anything that "just worked" before upgrading is the suspect list.
• Published configs win. mergeConfigFrom only fills in missing keys. If you published the config under the old defaults, v1.0.6's new defaults will never reach your app. Manually reconcile the file — don't assume a composer update fixes it.
• Stale config cache. Always config:clear locally and re-run config:cache in the deploy step; otherwise you'll debug a behaviour change that isn't actually deployed.
• .env precedence. If the config uses env(...) with an explicit default of false, an existing PKG_VENDOR_PACKAGES=true in .env or the server environment still wins. Audit env vars per environment before concluding the fix "didn't apply".
• Debugging tip. Dump the effective values at runtime rather than reading the file: php artisan tinker → config('<package>.vendor_packages') and config('<package>.auto_translate'). Compare against the config file to spot cache/env overrides immediately.
• Vendor support is a performance and correctness lever. Enabling it can pull in third-party translations/strings you don't control; if the flag accepts a list, prefer an allowlist of specific packages over true.
• Extension point. If the package resolves these flags in a service provider or dedicated resolver/config class, that's the hook to override in your own provider — subclass or bind your own implementation rather than editing the vendor file, so future default changes don't clobber you.
• Version pin sanity. This is a patch release, so it should be drop-in, but the default change is behaviourally significant — pin to ^1.0.6 (not *) and scan the changelog for v1.0.7+ before the next blind composer update.

Assumption note: the specific config keys and command names above are generic placeholders. Confirm them against the package's config/ file and README before applying; the release notes do not name them explicitly.