- What is keevitaja/linguist and how does it differ from Laravel's built-in localization?
- Linguist is a Laravel package that replaces the default file-based translation repository with a database-backed store, so language strings live in a table instead of lang files. It adds a management web UI, a service provider, a facade, and locale-detection middleware for multilingual URLs and redirects. It plugs in at the Translation Loader contract level, so it is a bounded substitution of the loader rather than a rewrite of Laravel's translator. That makes it attractive when non-engineers need to edit copy at runtime.
- Does keevitaja/linguist support Laravel 9, 10, or 11 with PHP 8.1+?
- Not out of the box. Linguist comes from the Laravel 5.x era, so its Composer constraints, provider registration style, and helper usage are likely incompatible with Laravel 9 and above without patching. Plan for a fork-and-fix effort instead of a simple composer require. Run Rector and PHPStan against your target PHP version to surface removed helpers and deprecated container and facade patterns.
- How do I install keevitaja/linguist in a modern Laravel application?
- Treat it as an internal fork: vendor it through a VCS or path repository, pin it to a specific commit, and never track upstream master. You will also need to publish and run the translations table migration, register the service provider and middleware alias, and configure caching. Publishing to an internal package registry keeps installs reproducible across environments. Budget time for a compatibility patch before anything reaches a shared branch.
- Is keevitaja/linguist still maintained and safe to use in production?
- The package is effectively archived, which means no security response, no framework-compatibility cadence, and no maintainer accountability. With zero dependents there is little ecosystem pressure keeping it alive and limited evidence of hardening under real production load. That is a permanent, unbounded liability rather than a one-time integration cost. A database-backed translation editor also adds an authenticated write path to user-facing copy, so it needs content-governance review like any CMS.
- What are the best alternatives to keevitaja/linguist for database-driven translations?
- Evaluate in this order: native Laravel localization with a release-driven translation workflow, then a maintained database-backed loader such as spatie/laravel-translation-loader, and only then a forked Linguist. Native lang files plus JSON translations cover most teams with zero third-party surface. A fork only wins if runtime editability by non-engineers is a validated requirement rather than an assumed convenience.
- How does Linguist's locale detection middleware and multilingual URL handling work?
- Linguist ships middleware that resolves the active locale per request and supports multilingual URLs and redirects. After forking, you must confirm middleware alias registration and route publishing work on your target Laravel version. Add tests around key resolution, fallback chains, and redirect behavior, since locale detection is where subtle regressions appear.
- Can I import my existing lang files into the Linguist database?
- Not automatically, so plan to build seed and import tooling from your existing lang and JSON files. You will need the translations table migration, an import command, and ideally export tooling so you can leave the package later. Verify how nested keys, pluralization variants, and JSON translations map into rows. Keeping a round-trip export is the cheapest insurance against lock-in.
- Does Linguist handle pluralization, JSON translations, and validation messages correctly?
- This is a real risk area because a database-backed loader can silently shadow native pluralization, JSON translations, and validation messages. Confirm conformance to the current Translation Loader contract and test key resolution and fallback chains explicitly. Include pluralization cases and framework validation strings in your test suite. If behavior diverges, patch the fork rather than working around it in application code.
- Is a database-backed translation editor a good fit for a multi-tenant Laravel SaaS?
- Usually not without a deliberate tenancy design. A shared translation table becomes a coupling point for multi-tenant or API-only services, and the tenancy strategy must be decided before adoption rather than after. Linguist fits best in a Laravel monolith with a small non-technical content team and a single default locale plus a handful of translations. High-tenant-count SaaS products should prefer per-tenant overrides in a maintained package.
- How should I test and harden a forked Linguist before going live?
- Start with a timeboxed spike of one week or less on an isolated branch that proves boot, translation resolution, and editing on your target Laravel version. Then write the compatibility patch with tests covering key resolution, fallback chains, and pluralization. Audit the editor routes for authorization, CSRF, and input sanitization before they reach any shared environment. Finally, name the engineer or team who owns the fork, the quarterly hours budget, and the exit path if the requirement disappears.