Translation Log Bundle Laravel Package

Product Decisions This Supports

• Localization quality as a tracked metric, not a vibe. The problem is real: missing keys surface to users as raw strings (checkout.title) or silent English fallbacks, which reads as a broken product in localized markets. Any team shipping more than one locale has this defect class, and it is invisible without instrumentation. A miss log gives you a count, not an opinion.
• Prioritizing localization spend. Misses ranked by frequency, locale, and route turn "translate everything" into a ranked vendor backlog — highest-traffic untranslated strings first. Dead-key visibility also lets you retire stale strings and shrink ongoing vendor cost.
• Release gating for market launches. "Zero observed misses in top N locales over the last 7 days" is a defensible pre-launch gate for a new market and a regression alarm for existing ones.
• Build vs. buy: this package is evidence for build. With 0 stars, 0 dependents, and no maintenance signal, adopting it is a liability transfer, not a buy decision. The capability is a translator decorator plus a log channel — roughly 1–2 engineer-days in-house and fully owned.
• Stack-fit caveat that changes the decision. This is a Symfony bundle, not a Laravel package. It cannot be installed into a Laravel application. For a Laravel team, its only value is as a design reference for the pattern.
• Roadmap signal. If misses cluster in one locale, that is evidence the i18n process is failing — string extraction, vendor turnaround, or key discipline — which is a roadmap line of its own, not a tooling gap.

When to Consider This Package

Adoption would require all of the following, which is unlikely to hold:

• You are on Symfony, not Laravel.
• Your Symfony version lacks, or your needs exceed, the framework's built-in missing-translation logging (framework.translator.logging), which routes misses through the standard logger and makes this bundle largely redundant.
• You cannot allocate the small effort to write the subscriber yourself.
• You accept indefinite maintenance risk on an unmaintained dependency with no community to inherit it.

Look elsewhere — or build — in essentially every other case:

• Symfony: enable native translator logging first. If insufficient, a short event subscriber is cheaper than vetting this bundle.
• Laravel: no built-in equivalent, but a translator decorator (or the version-appropriate missing-key hook) plus a dedicated Monolog channel covers it. Do not attempt to bridge a Symfony bundle into Laravel.
• Buy: if the goal is outsourced localization operations, Phrase, Lokalise, Crowdin, or Weblate ship missing-key detection natively and are the correct purchase.
• Shift left: static extraction and template scanning catch misses pre-production and complement — do not replace — runtime logging, which is the only thing that catches dynamic keys.

How to Pitch It (Stakeholders)

To executives: "A tool exists for a genuine quality problem — users in localized markets seeing untranslated strings. However, it is a zero-adoption, unmaintained Symfony bundle that does not fit our Laravel stack. Recommendation: do not adopt. The useful capability can be replicated in one to two engineer-days and owned outright, which is cheaper than integrating, security-reviewing, and eventually forking an abandoned dependency. We keep the outcome — visibility into translation gaps — and drop the dependency risk."

To engineering: "The pattern is worth stealing even though the package is not: hook the translator's missing-key event (or decorate the translator), capture key, locale, route, and release, write to a dedicated async log channel, sample or dedupe to prevent log floods, log parameter names not values to stay PII-safe, and emit a weekly digest plus a launch-checklist query. Fail open — logging must never break a page render. Confirm first whether our framework version already logs misses via configuration — likely yes on Symfony, no on Laravel — so we do not rebuild something we get for free. Scope it as a small internal utility with tests and a named triage owner, not a vendor integration."