Translation Laravel Package

Product Decisions This Supports

• Market expansion sequencing. The component is the enabling layer for any "ship in locale X" roadmap item. Because it supports pluggable loaders (array, XLIFF, YAML, CSV, DB) behind one trans() API, the decision to enter a new market becomes a content/ops decision rather than an engineering one — a new locale is a catalog plus a config change, not a sprint. This is what lets you commit to launch dates for additional markets without re-litigating architecture each time.
• Build vs. buy for translation management. Two separable decisions: (1) the runtime — never build this; it is commodity infrastructure with 6.6k stars, MIT license, and continuous maintenance across the 6.4/7.4/8.x branches; (2) the workflow — Symfony ships providers for Crowdin, Lokalise, and Phrase, so the runtime does not lock you into a vendor. That preserves the option to start free (file-based catalogs, zero license cost) and upgrade to a TMS only when string volume or translator headcount justifies it. Frame the buy trigger explicitly: roughly >5 locales or >10k strings, or when a non-engineer needs to edit copy.
• Laravel-layer vs. component-layer decision. symfony/translation is already in the dependency tree of laravel/framework, so the question is not "adopt or not" but "where does our code call in." Default should be Laravel's __() / lang/ wrappers. Escalate to direct component use only for specific needs: XLIFF catalogs shared with a TMS, ICU message formatting for plurals/gender/currency, TranslatableMessage objects flowing through domain/queue layers, message domains for separating product vs. legal vs. notification copy, and catalogue diffing to compute translation completeness as a release gate.
• Release-gating and quality metrics. Catalogue operations (merge, diff against a reference locale) let you define a hard, automatable definition of done — e.g. "no locale ships below 98% coverage on user-facing domains." That turns localization from a vague QA concern into a measurable launch criterion, and it is the single most useful thing a PM can extract from this package.
• Infrastructure cost and upgrade planning. Open-source, MIT, no seat fees; the real cost is version coupling. Symfony 8.x requires PHP ≥ 8.4, and Symfony's support windows (LTS branches like 6.4 vs. standard 8-month minor support) set the cadence for your PHP upgrades — which in turn constrains your Laravel major-version upgrades. That belongs on the platform roadmap, not in a ticket.
• Scoring caveat for the portfolio review. The 58.8 score and 0 dependents are measurement artifacts, not risk signals: development happens in the symfony/symfony monorepo, so stars, issue activity, and dependents all undercount. Treat this as tier-1 infrastructure and judge it on release cadence and LTS policy instead.

When to Consider This Package

Consider adopting (directly or via Laravel's wrappers) when:

• You are shipping to two or more markets, or contractually obliged to (enterprise procurement, public-sector tenders, app-store listings per region).
• Content must be exchanged with translators or a TMS in a standard format — XLIFF 1.2/2.0 support here is the practical difference between a translator working in their own tool and someone hand-editing PHP arrays.
• You need correct pluralization, gendered wording, or locale-aware number/date/currency formatting. Hand-rolled str_replace pluralization breaks in Slavic and Arabic locales first, and finance-facing bugs are expensive.
• Translation must work outside the HTTP request cycle — queue workers, scheduled jobs, CLI commands, event consumers. Locale propagation is where naive setups quietly serve English to French users.
• You need per-domain separation of strings (product copy, validation, legal, emails) so that legal review, translator assignment, and coverage metrics can be scoped.

Look elsewhere, or stay with defaults, when:

• Single locale, or a small fixed set of strings. Laravel's lang/*.php and __() are sufficient and idiomatic; do not add an abstraction for its own sake.
• You need content localization rather than interface localization — user-authored or CMS records translated per row. Use spatie/laravel-translatable or a dedicated content model; this component translates message IDs, not database entities, and forcing it to do so is a common and costly mistake.
• You actually want a translation workflow — translator UI, review states, screenshot context, per-string history. Buy Phrase/Lokalise/Crowdin and consume their output; do not build a TMS on top of a catalogue library.
• Your team is Laravel-only and the requirement is ordinary web UI strings. Adopting the component directly creates two parallel translation stacks — duplicate catalogs, divergent fallback order, and confusing locale-switching semantics. If you do adopt it, adopt it fully for that surface and document the boundary.

Adoption risks to price in: version coupling to PHP/Laravel upgrade cycles; the absence of a security policy or contribution guide in this split repo (they live in the monorepo, which slows third-party audit); and the 8.x return-type enforcement plus removals (TranslatableMessage::__toString(), CsvFileLoader::$escape) that make this a semver-major migration surface, not a drop-in.

How to Pitch It (Stakeholders)

To executives: This is free, MIT-licensed plumbing that determines how cheaply we enter new language markets. It is already inside our stack as a Laravel dependency, so the decision is about how we use it, not whether to buy it. Used well, it converts "launch in market X" from an engineering project into a content project with a predictable cost, and it lets us postpone or avoid five-figure annual translation-platform fees until volume actually justifies them. It also gives us an objective, automatable launch gate — percentage of user-facing strings translated per locale — instead of a subjective "the translations look done." The cost is an upgrade-cadence commitment: we track Symfony's LTS windows, which in practice sets when we move PHP and Laravel majors. Recommendation: adopt as standard infrastructure, no procurement needed, with a decision point to revisit paid tooling once we exceed roughly five locales or ten thousand strings.

To engineering: Use Laravel's __() and lang/ as the default surface; reach for the component directly only for XLIFF/TMS interop, ICU formatting, translatable domain objects, and catalogue diffing in CI. Never run two translation stacks on the same surface. Pin to an LTS branch, expect breaking changes at majors, and put locale propagation (queue, CLI, scheduled jobs) in the initial design rather than retrofitting it — that is where internationalization bugs actually come from. Budget a small, bounded spike to confirm the boundary before committing; this is low-risk, low-differentiation infrastructure and should not consume roadmap attention beyond that.