- How do I install babelqueue/laravel in a Laravel application?
- Install the package with Composer using composer require babelqueue/laravel. Laravel's package auto-discovery registers the service provider, so no manual provider entry is normally needed. After installation, confirm the package's Composer constraints match your app's Laravel and PHP versions, then dispatch a test mailable or job to verify locale restoration.
- Which Laravel and PHP versions does BabelQueue support?
- BabelQueue is a Laravel package, so its supported Laravel and PHP range is defined by the illuminate/* and php constraints in its composer.json. The supplied overview does not publish a version matrix, so check those constraints against your application before adopting it. If you run an older Laravel major or a lower PHP floor, verify compatibility first rather than assuming the latest release supports it.
- How does BabelQueue restore the correct locale inside a queue worker?
- BabelQueue captures the active application locale at the moment a mailable, notification, or job is dispatched and restores it inside the queue worker. That keeps translated content aligned with the user who triggered the work, even when the worker process runs under a different locale. This avoids manually capturing app()->getLocale() into every job payload and reapplying it in each handler, which is the usual alternative.
- Do I need to publish or edit a config file after installing BabelQueue?
- BabelQueue advertises zero-configuration setup through an auto-discovered service provider, so you can start without publishing a config file. Configuration matters mainly for the fallback locale and any environment-specific behavior; check the package docs for whether its config file is publishable. If it is publishable, keep environment-specific values out of version control as you would for any Laravel package config.
- How do I set a different locale for a single queued job or mailable?
- BabelQueue supports per-job locale overrides for cases where a single dispatch targets a different language than the dispatcher's active locale. Apply the override at the dispatch site so the worker restores the intended recipient locale rather than the captured default. Use this for multi-language recipients, and add a test that asserts the overridden locale inside the job.
- Does BabelQueue work with custom queued jobs, not just mail and notifications?
- BabelQueue supports queued mailables, notifications, and custom jobs, not just mail. For custom jobs, the locale is restored when the job runs in the worker so translations resolved during handling use the dispatcher's locale. Verify your own job classes are dispatched through the queue normally, since synchronous execution bypasses the worker path entirely.
- What locale does BabelQueue use when none can be detected at dispatch time?
- When no locale can be detected at dispatch time, BabelQueue can use a configurable fallback locale. Set that fallback deliberately to your application's default language so worker output never silently renders under the worker's own locale. Test the fallback path by dispatching a job with no active locale and asserting the resulting translations.
- Will BabelQueue work with Redis, SQS, and database queue drivers?
- BabelQueue's locale handling is application-level, but the technical assessment flags queue driver assumptions as something to confirm before production. Test on the driver you actually run, whether Redis with Horizon, SQS, or the database driver, because serialization, retries, and backoff behavior differ. Also check that the package does not alter job serialization or failure handling in ways that affect in-flight work.
- How should I test that locale is captured and restored in my queue workers?
- Dispatch a job under a known locale, process it with a queue worker or queue fake, and assert that app()->getLocale() inside the job equals the dispatcher's locale. Add coverage for the fallback locale and any per-job overrides, since those are the paths most likely to regress. Run this suite on your real queue driver in staging before relying on it in production.
- Is upgrading from BabelQueue 1.5.1 to 1.6.0 safe, and what changed?
- The move from 1.5.1 to 1.6.0 is a minor semver bump, which suggests additive and backward-compatible changes, but the supplied release artifact is only a changelog compare link. Treat compatibility as unverified: diff published config and migrations between tags, look for new or renamed required config keys, and run your full test suite before upgrading. For queue-critical code, ask the maintainer for the enumerated change list and confirm nothing alters serialization, retries, or failure handling.