Matice Laravel Package

Product Decisions This Supports

• Localization strategy / i18n roadmap: Deciding whether translations live in version-controlled lang/ files (developer-owned) or in the database (editor-owned). Matice backs the second model — it stores translations in DB tables and exposes a management UI, so content and marketing can ship copy changes without a deploy or an engineer.
• Build vs. buy for translation management: A credible "build-light" option versus Lokalise/Phrase/Crowdin or spatie/laravel-translation-loader. Low integration cost (Laravel-native, no external vendor, no per-seat or per-word pricing) makes it attractive for teams that need editing capability but not full TMS workflow.
• New in 1.3.0 — scoped rollout of editable copy: the @translations Blade directive now accepts only/except overrides. This lets a PM phase a migration rather than doing a flag-day switch: render DB-managed strings only for the sections/keys a given view should own (e.g. a marketing landing page or checkout microcopy), while the rest of the app keeps reading static files. It also limits blast radius when non-technical editors have write access — they can only affect the groups you surface.
• New in 1.3.0 — platform currency: the preg_split() null-limit deprecation fix future-proofs the package for PHP 8.4, which materially affects upgrade planning if PHP 8.4 is on your platform roadmap this year. The CI change (disabling Composer security-advisory blocking to test older Laravel releases) is a testing-only relaxation, not a runtime one — but it does mean the CI signal is slightly weaker than "installable with advisories enforced."
• Use cases worth evaluating: admin-editable UI strings, per-tenant/white-label copy overrides, placeholders and dynamic values in translated strings, and multi-locale MVPs where a dedicated localization hire or vendor contract isn't justified.

When to Consider This Package

Consider it when:

• You are on Laravel, have a small-to-moderate string inventory (roughly a handful of locales, not dozens), and want a UI for non-developers to edit copy.
• You want translations decoupled from deploys — copy changes shipping on a content cadence, not a release cadence.
• You have per-tenant or per-client text variance that static lang/ files handle poorly.
• You want no external service dependency, no vendor contract, and no data-residency questions about shipping product copy to a third party.
• You can accept DB reads on translation lookup (verify the package's caching behavior against your hot paths before committing).

Look elsewhere when:

• You need professional translator workflows — assignment, review/approval, translation memory, glossary enforcement, machine-translation integrations. That is TMS territory; Matice is an editor, not a workflow engine.
• You need ICU MessageFormat, complex pluralization, or locale-aware formatting beyond simple replacement.
• You treat translations as source code (review, diff, blame, rollback via VCS) — DB-backed strings lose that.
• You are serving translation-heavy, latency-sensitive traffic and cannot guarantee caching.
• You require an actively supported package with a broad maintainer base; this release is largely maintenance and two first-time contributors, so bus-factor and long-term support are worth weighing for a long-lived product.

Adoption guardrails: pin the version, confirm Laravel/PHP support against your matrix (CI covers older Laravel releases but with advisory blocking disabled — validate in your own pipeline), and define who owns editorial access before enabling the UI.

How to Pitch It (Stakeholders)

To executives: This is a small, Laravel-native dependency that lets marketing and content edit in-product copy directly instead of filing tickets for developer releases. The business case is cycle time and engineering toil, not capability — we ship copy changes in minutes rather than days, and we avoid a translation-vendor contract for a need that doesn't yet justify one. Cost is a Composer dependency plus modest integration effort; there is no license fee and no product copy leaving our infrastructure. Risk to note: it is a small open-source project, so we pin the version and keep static language files as the fallback. Recommendation is to adopt it for editor-owned copy only, not as the system of record for all strings.

To engineering: 1.3.0 is a low-risk upgrade — no breaking changes. The substantive addition is only/except on the @translations directive, which lets us scope which translation groups a view or editor surface touches, so we can migrate copy incrementally instead of all at once. The release also fixes a preg_split() null-limit deprecation for PHP 8.4 readiness, which matters for our platform upgrade path. One caveat: CI now disables Composer security-advisory blocking to test older Laravel versions, so that pipeline is not our security gate — our own audit step remains authoritative. Validate lookup performance under cache and confirm our Laravel/PHP versions are covered before rollout.