Translation Yaml Tools Bundle Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. The package's core value is turning "which locales do we ship, and when?" into an operational question rather than an engineering one. Because it detects keys that are missing per locale, it gives you a concrete, per-locale completeness number you can put in front of stakeholders when deciding whether to launch a market with full translation coverage or with a documented subset.
• Build vs. buy vs. defer on translation tooling. This sits in the gap between "engineers hand-edit YAML" and "buy a TMS (Crowdin, Lokalise, Phrase)." A PM can use it to defer a five-figure TMS contract for a release or two while the locale count is still small, then revisit when reviewer workflows, glossaries, and vendor management actually become the bottleneck rather than the file format.
• Machine translation policy. The pluggable provider design (Google, DeepL, LibreTranslate, custom) makes "which MT vendor, and do we allow MT at all?" a reversible, config-level decision instead of an architecture commitment. That supports a staged policy: MT for internal QA builds and non-revenue locales first, human review for revenue-facing copy, and a clean swap if a provider's pricing or quality changes.
• Cost scoping for translation spend. Per-key, per-locale missing-key detection is the input to any credible MT cost estimate. You can quantify "adding German and Japanese costs roughly N segments at provider rate X" before committing to a market launch, which is the difference between a defensible budget line and a guess.
• Engineering capacity allocation. The bundle absorbs the boring, error-prone parts of i18n maintenance — nested tree flattening, key sorting, diffing catalogs — that otherwise consume recurring sprint time or, worse, get skipped and produce drifted, alphabetically chaotic, merge-conflict-prone translation files. It is a plausible argument for not hiring a localization engineer yet.
• Release-readiness gating. "No missing keys in the shipping locales" is a cheap, automatable acceptance criterion. This package makes that criterion enforceable in CI rather than a manual pre-release checklist item, which is the kind of decision that reduces launch-day incidents.
• Fork-or-adopt risk posture. With 0 stars, 0 dependents, and a single-maintainer signal, this is a decision input rather than a settled dependency. The MIT license and the narrow, tooling-only scope (console commands, no runtime surface) mean the realistic PM-approved path is: pilot it, and if it proves useful, vendor the commands into your own repo. That is a defensible "buy small, own the risk" call that a PM can make without an architecture review.

When to Consider This Package

Consider it when all or most of the following hold:

• Your stack is PHP with Symfony's console and translation components — this is a Symfony bundle with a DI extension and compiler-pass wiring, not a Laravel package. On Laravel you would be adopting the underlying Symfony console tooling and translation-file conventions alongside Laravel's own lang/ structure; expect integration work, not a composer require and go. Confirm this before it enters a roadmap.
• Your translation catalogs are YAML files under version control. If you use PHP array catalogs, JSON, database-backed translations, or a hosted TMS as the source of truth, most of the value evaporates.
• You are managing multiple locales with a small team, and catalog churn is a recurring, low-grade annoyance: unsorted keys producing noisy diffs, nested structures that are hard to reason about, and missing keys discovered in production.
• You want MT as an accelerator, not a replacement for review — i.e., you accept that machine-generated strings go through a human or QA pass before customer exposure.
• You can tolerate low ecosystem maturity: 0 stars, 0 dependents, and a release date (2026-10-24) that reads as anomalous relative to today. Treat that combination as "unproven software from an unknown maintainer" and plan for reading the source. The MIT license at least means you can fork and maintain it internally if it earns its place.
• Your organization has PHP/Symfony literacy in-house to own a fork if upstream goes quiet.

Look elsewhere when:

• You need a TMS with translator-facing UI, review states, glossaries, translation memory, or per-string approval workflows. This is a developer tool, not a localization platform; it will not replace Crowdin-class tooling once you have non-engineer translators.
• You need vendor SLAs, security review artifacts, or procurement-approved dependency support. Nothing here suggests that exists.
• Your translations are runtime-editable (admin panels, per-tenant overrides, CMS-authored copy). File-based console tooling is the wrong model.
• Legal/compliance constrains MT. Sending product strings to Google or DeepL may violate data-handling policy for certain content; the pluggable-provider design helps only if you are prepared to run LibreTranslate or an internal model, which is its own project.
• Your translation volume is truly tiny — one locale, a few hundred keys. A shell script or a linter rule is cheaper than a dependency decision.

How to Pitch It (Stakeholders)

The one-liner: a small, MIT-licensed developer tool that automates the tedious parts of keeping translation files in order and can machine-translate missing strings on demand — it buys us time before we need a paid localization platform.

For executives: we have a recurring, low-visibility cost in shipping multiple languages: engineers hand-maintain translation files, keys drift out of sync, and missing strings surface after release. This tool makes catalog completeness measurable, keeps files diff-friendly, and lets us fill gaps with machine translation using whichever provider is cheapest or approved at the time. It is a build-and-CI tool, not production code — it carries no runtime risk to the application, and its provider layer means we are not locked into any translation vendor. Recommendation: timeboxed pilot, no procurement, no platform commitment. Expected outcome is either a measurable reduction in per-release i18n toil or a fast "no" that costs us a day.

For engineering: it is a Symfony console bundle — nested-tree conversion, key sorting, and a pluggable MT layer for missing keys. It slots into our existing translation-file workflow and CI. Two caveats to own: it is Symfony-shaped, so Laravel needs adaptation, and it has essentially no adoption (0 stars, 0 dependents) with a single-maintainer profile. Plan to evaluate the source and be ready to vendor the handful of commands we actually use. It is MIT, so forking is a legitimate end state, and because it only touches YAML catalogs at build time, the blast radius of adopting it is small.

What I need from you: one engineer-day for a spike against our two busiest locales, and agreement on the MT policy — which providers are approved and which content is off-limits to machine translation. If the spike shows missing-key count dropping in CI and sorted, conflict-free diffs, I will bring a scoped adoption proposal; if not, we close it and keep the current checklist.

What this is not: it is not a translation management system, it will not give translators a review UI, and it does not reduce the need for human review of customer-facing copy. It lowers the cost of maintenance, not the cost of quality.