Tomato Translations Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. The v1.2.6 addition — an Artisan command that translates a selected path rather than the entire application — is the decision-relevant feature. It turns localization from an all-or-nothing launch gate into a scoped, repeatable workflow: localize one module, one domain, or one new feature per sprint, ship it, and measure. A PM can sequence market entry incrementally instead of funding a full-app translation sweep up front.
• Market-expansion go/no-go. For any locale on the roadmap, this package is a cheap way to run an "extract → translate → review → ship" pilot loop. Path-scoped translation lowers the cost of validating one locale before committing budget to a formal i18n program or a TMS contract.
• Build vs. buy for internal localization tooling. The recurring "should we build our own translation admin?" question gets an interim answer: an existing package with a web-based editing UI plus a scriptable CLI escape hatch. The CLI piece is usually the argument that kills homegrown tooling, because it can live in a release runbook instead of being a manual chore.
• Workflow/DevEx investment, not new capability. The package is ergonomics: a UI for editing keys plus machine-assisted generation. It is a signal that the maintainer is optimizing for incremental, ad-hoc usage — relevant when deciding between this and raw lang/ files plus a spreadsheet.
• Operational risk posture. A command surface introduces new failure modes in automation — bad path selection, partial overwrites of human-curated copy, API failures, and rate limits. Frame it internally as "a capability to trial behind review," not a release-blocking CI dependency.
• Caveat on the evidence base. The signal here is one release note and a single commit on a package with negligible adoption (2 stars, 0 dependents, last release April 2024). Any adoption recommendation should be provisional and timeboxed; release cadence, issue responsiveness, and test coverage are unestablished.

When to Consider This Package

Consider it when:

• The product is a Laravel app already on (or committed to) the TomatoPHP/Filament stack — integration cost drops sharply and the admin editing surface comes nearly free.
• Localization is a recurring need rather than a one-time translation of a static file: multiple locales, strings changing every sprint, and non-engineers who need to edit copy without touching PHP/JSON.
• You want a path-scoped, scriptable translation step so "translate only the module we just changed" becomes a pipeline stage instead of an all-or-nothing regeneration.
• You need to demonstrate localization progress cheaply — a pilot locale, a bounded scope — before funding a TMS (Crowdin, Lokalise, Phrase) or a dedicated localization owner.
• A human review gate exists and machine translation is expected to produce drafts, with a diff as the review artifact.

Look elsewhere when:

• You need translation memory, glossary enforcement, translator collaboration, per-locale QA sign-off, or auditable approval chains — that is TMS territory and a package-level tool will not substitute.
• You are not on the Laravel/TomatoPHP stack; value degrades to "yet another lang-file editor" with integration cost exceeding benefit.
• Compliance, brand, or legal requirements demand role-gated review of user-facing copy before it ships.
• You need maintenance guarantees or vendor support. Single-maintainer, near-zero-adoption ecosystem packages carry concentration risk that must be priced in — and a last release over a year old is itself a signal.
• Unreviewed machine translation of customer-facing copy is unacceptable. Note the tension: this package makes bulk machine translation easier, which raises rather than lowers the governance bar.

How to Pitch It (Stakeholders)

For executives: We can localize incrementally instead of running a big-bang translation project. This package gives us a translation admin surface plus a command that translates only a specified part of the codebase, so we can localize one module per sprint, ship it, and measure adoption in a new market before funding the next. It is inexpensive to trial, sits in front of lang/ files we already control, and does not lock us in. Honest caveats: it is a small open-source component with very little adoption and a single maintainer, and its last release was April 2024. Recommendation is a pilot on one non-critical locale with human review in the loop — not auto-shipping machine-translated customer-facing copy.

For engineering: The v1.2.6 feature is an Artisan command that takes a path, so translation can be scoped to a directory or module rather than the whole app. That is the first version where the package is genuinely scriptable — usable as a release task. Recommended pilot: one low-risk locale, one bounded path, verify output quality, and confirm behavior on nested lang files and namespaced keys before wiring anything into CI. Keep generated strings behind code review and treat them as drafts. Open questions to resolve before committing: exact command signature and options (--locale, --force, --dry-run, --path); whether it overwrites, merges, or skips existing keys; idempotency on re-run; dry-run/diff artifact for review; how "path" resolves (directory, glob, namespace); Google API key handling, quotas, retries, and partial-failure behavior; supported Laravel/PHP versions and storage formats; and test coverage for the new command. The upgrade itself is patch-level and additive — low migration risk — so pin the version, branch it, and validate before team-wide adoption.

Ask: approve a timeboxed spike — one engineer, one sprint, one locale, one scoped path — with a go/no-go decision based on string quality, repeatability, and safety of the write behavior.