Laravel Translation Laravel Package

Product Decisions This Supports

• Localization roadmap: This package covers the infrastructure layer for multilingual content — dynamic model translations stored per-record, multi-locale request handling (TranslationTypeObjectRequest, MultiTranslationArrayRequest), and field-level validation (TranslationFieldExistRule). PM decisions on "which locales at launch," "translated CMS content vs. static UI strings," and "user-generated content in N languages" can be scoped against this rather than estimated as greenfield work.
• Build vs. buy: The 3.0.0 release is effectively a maturing internal package — moved into the panelify/translation namespace, new Translation model, factory, and migrations included. That means the "build" cost for translation persistence, validation, and model traits is already paid; the remaining product cost is admin UI and editorial workflow, not backend plumbing.
• Multi-tenant / multi-panel architecture: The move to panelify/translation and the new design for request objects signals this is intended as shared infrastructure across panels/apps. Supports decisions about consolidating translation handling in one place vs. per-app implementations.
• Admin and editorial tooling: TranslationForgetEvent and the model/factory additions enable cache invalidation and testable seeding — the groundwork for a translation management screen, import/export, and QA of missing strings. Roadmap items like "edit translations without a deploy" become viable.
• Upgrade planning and risk: 3.0.0 is a breaking release (removed TranslationContract, renamed/changed request classes, migration changes). This feeds directly into decisions about when to absorb the upgrade, whether to freeze the old version during a launch window, and how much engineering time to reserve.

When to Consider This Package

Adopt when:

• You need database-backed translations per model record (product names, descriptions, articles) rather than only static lang/ files.
• You are standardizing localization across multiple Laravel apps or panels and want one consistent trait, model, and validation story.
• Your team already writes Form Request classes — the package's request objects (TranslationArrayRequest, MultiTranslationTypeObjectRequest) slot into that pattern and reduce custom validation code.
• You want test support out of the box — the release adds factories, test files, and a language service provider in the base test case, lowering the cost of writing localized feature tests.

Look elsewhere or build custom when:

• You only need static UI string translation — Laravel's built-in lang files plus a translation service are simpler and avoid a schema dependency.
• You are on a tight deadline during 3.0.0's stabilization window — this release removes a public interface and reworks core request classes and migrations; the changelog shows heavy churn (e.g. class_uses_recursive swapped back and forth to is_subclass_of), which suggests the trait-detection behavior is still settling.
• You need vendor-backed support or a long-term compatibility guarantee — this is a first-party-namespaced package with a fast-moving major version history.
• Your localization needs are content-centric with heavy editorial workflow (translation memory, vendor TMS integration, review states) — that is a different product category.

How to Pitch It (Stakeholders)

For executives: The translation package has reached 3.0.0, which consolidates multilingual content support into a single shared component for our Laravel applications. The practical effect is that we no longer need to build translation storage, validation, and model-level language handling from scratch for each product — that work is now reusable infrastructure. The cost of the upgrade is a one-time engineering effort, not a recurring one, and it unblocks localization features on the roadmap that would otherwise require new headcount or a third-party contract.

For engineering: Plan a dedicated upgrade task, not a background dependency bump. 3.0.0 is breaking: TranslationContract is removed, the request objects (TranslationTypeObjectRequest, TranslationArrayRequest, and the Multi* variants) have new designs, the model trait now uses class_uses_recursive for detection, and the migrations have changed — including added indexes. Treat this as a scoped migration with a test pass, and validate the new migrations against production data volume before rollout, since index changes on translation tables can be slow. The upside is meaningful: factories, a full test suite for requests, rules, and traits, an event for cache invalidation, and a cleaner package boundary under panelify/translation that makes this maintainable long-term. Recommend we pin the current version until the migration branch is green, then adopt across panels in a single coordinated window to avoid mixed-version translation behavior.