- How do I install and configure torann/localization in a Laravel app?
- Require it with Composer, pinning to ^2.0 (2.0.4 at the time of evaluation), then publish config/localization.php and add the package middleware to the web group in bootstrap/app.php after TrustProxies. Set URL::defaults(['locale' => ...]) so route() emits locale-correct URLs, and add a locale-switch redirect that validates the requested locale against your configured allowlist before redirecting. The integration itself is days of work for a single market; the real cost is the surrounding work such as apex-host behavior, hreflang, cookie scoping, and auditing route() calls from console commands, jobs, and mailables.
- Does torann/localization support Laravel 11 and Laravel 12?
- Integration feasibility is high for a Laravel 11/12 codebase, since the package is a standard service provider plus request middleware that composes with Laravel's native translator, Blade, and lang/{locale} files. Because the package is thin and single-maintainer, confirm the framework constraints in its composer.json and run your own smoke tests on the exact version you plan to ship. Pin the version rather than floating it, and if you vendor the code you control compatibility directly.
- How does torann/localization detect which locale to use?
- Its core mechanism derives the active locale from the request host, matching subdomains such as fr.example.com against a configured allowlist in config/localization.php, with documentation also describing browser-header and session-based detection. Because every bit of that state ultimately comes from client-supplied input, the allowlist validation is load-bearing: an unvalidated locale that reaches redirect(), a cache key, or URL::defaults() is a real risk. Ensure TrustProxies is configured correctly behind your CDN so the host is resolved as intended.
- Can torann/localization use subdirectories like example.com/fr instead of subdomains?
- No. The package presumes a subdomain-per-market URL convention, which makes it a cheap accelerator if your organization has already committed to subdomains and the wrong tool if the URL architecture is still open. Choosing between subdomain, subdirectory, and cookie/header strategies is a hard-to-reverse platform decision, so treat adoption as that decision rather than a routine dependency pick. If subdirectories or translated route slugs are required, evaluate mcamara/laravel-localization instead, and do that comparison before launch.
- Does torann/localization do database-backed translations and translatable model attributes?
- Some package blurbs advertise database-driven translations and translatable attributes, but the repository metadata describes a simple subdomain localization component, and that conflict is a documentation-quality signal you should resolve by reading the source. Laravel's existing lang files and the __() helper work without modification either way, so keep lang/*.php as the initial source of truth until you confirm what the database layer actually provides. Do not scope a roadmap item on an artifact whose own docs disagree about what it does.
- How does torann/localization behave with Laravel Octane and queue workers?
- Locale is process-global state, so long-lived Octane workers and queue processes will happily serve the wrong language unless the locale is set per request and carried explicitly on job and mail payloads. Anything that calls route() or the translator from a console command, queued job, or mailable needs an explicit locale rather than relying on ambient state. Audit those call sites early, because they are the most common source of post-launch localization bugs.
- Is torann/localization maintained enough to use in production?
- The supply-chain profile is thin: roughly 200 lines of code, a single maintainer, very few stars and no dependents, which means little ecosystem pressure to catch regressions and a likely failure on most dependency-intake scorecards. The BSD-2-Clause license makes vendoring essentially free, which converts trust-upstream into owning a small amount of code you have already read and reviewed. That is the recommended mitigation, budgeted at roughly a day, paired with a quarterly review of upstream diffs.
- How does torann/localization compare to mcamara/laravel-localization?
- Torann Localization is oriented around subdomain-per-locale routing, while mcamara/laravel-localization handles subdirectory URL prefixes and translated route slugs. It also does not perform Accept-Language negotiation or cookie fallback, so if those or translated slugs are requirements, that is a reason to look elsewhere. Make the comparison now rather than after launch, because switching URL strategies later carries real exit cost.
- How do I build a language switcher in Blade with torann/localization?
- Use the package's Blade helpers together with a dedicated switch route that accepts a target locale, validates it against the configured allowlist, and redirects to the equivalent path on the target subdomain. Never pass an unvalidated locale into redirect(), since that is a plausible open redirect, and keep URL::defaults(['locale' => ...]) set so route() generates locale-correct links throughout your views. Because the locale is exposed through app()->getLocale(), Blade, Livewire, and Inertia all read from the same source.
- What else do I need to handle alongside torann/localization for a multi-language site?
- The package does not cover canonical and hreflang tags, apex and unknown-host behavior (301, serve default, or 404), session cookie scoping to .example.com, or wildcard TLS, so plan those as separate work items. Also verify TrustProxies correctness behind the CDN, since locale resolution depends on a trustworthy Host header, and whitelist-validate every locale value before it reaches a redirect or cache key. Finally, define who owns translated content and its review workflow, and agree on who reviews upstream diffs if you vendor the code.