Translator Checker Bundle Laravel Package

Getting Started

This bundle is a Symfony 2.x-era tool from 2015 — treat it as a legacy component, not a current dependency. Before anything else, open composer.json on the repo and check the require block for the Symfony and PHP constraints. If you're on Symfony 4+, expect to fork and port it rather than composer require it as-is.

Minimal steps:

# 1. Confirm compatibility before install
composer show mdm/translator-checker-bundle --all   # or read composer.json on GitHub

# 2. Install (dev-master was the norm for this package)
composer require --dev mdm/translator-checker-bundle:dev-master

# 3. Register in app/AppKernel.php (Symfony 2)
new MDM\TranslatorCheckerBundle\MDMTranslatorCheckerBundle(),

Where to look first in the repo:

1. README.md — the primary usage doc; for a 14-star bundle from 2015 it's often the only documentation, and the command signature is usually in there.
2. Command/ — the console commands are the whole product. Read the configure() methods to learn exact option names before trusting any guess.
3. DependencyInjection/Configuration.php — the config tree tells you what locales, paths, and catalog formats you can point it at.
4. Resources/config/services.yml — reveals the scanner/parser services you can override.

Confirm the command name rather than assuming:

app/console list | grep -i translat
app/console help <command-name>

First use case: run it against one locale pair on one translation directory in a throwaway branch. The bundle is a reporting tool — see what it flags before you decide whether its "unused key" or "missing key" definitions match your team's.

Implementation Patterns

Reference-locale-first comparison. The useful workflow is: pick your source locale (usually en or fr for MDM) as the source of truth, then diff every other locale against it. Run it per target locale so failures are attributable, not a wall of mixed output.

Scope the scan paths deliberately. Point the checker at application translations (app/Resources/translations) and your own bundles, and explicitly exclude vendor bundles. Otherwise every third-party bundle's catalog pollutes the report and you'll stop reading it within a week.

CI as a report, not a gate (at first). Wire it into CI as a non-blocking job that publishes output as an artifact. Only flip it to blocking once you've suppressed the false positives you actually can't fix (dynamic keys, keys built in PHP).

# Example CircleCI/Travis-style step, adapt to your runner
- run:
    name: Translation consistency report
    command: app/console <checker-command> -e=prod || true

Pre-commit / pre-push hook. For a small team this is higher value than CI — catching a missing key in the same commit that adds the Twig |trans call keeps the catalog honest without a review cycle.

Pair with your existing extraction workflow. If you already run translation:extract (or a hand-rolled extractor), the checker's "missing" set is only meaningful if both tools agree on what counts as a key. Run them back-to-back in the same job so drift is visible.

Baseline file for false positives. If the bundle supports an ignore/whitelist option (check Configuration.php), commit that file. If it doesn't, keep the invocation narrow and grep the output in a wrapper script — you do not want every developer maintaining a private ignore list.

Gotchas and Tips

• It's 2015 software. Last release was January 2015, zero dependents, 14 stars. There is no maintenance, no Symfony 4/5/6 support, and PHP 7.2+ will surface deprecations (and likely fatals on PHP 7.4+/8.x). Budget a day to fork, pin symfony/* constraints, and fix removed APIs — or don't adopt it at all.
• Dynamic keys are the biggest source of noise. Anything like {{ ('messages.' ~ type)|trans }} or keys assembled in a controller is invisible to a static scanner. These will be reported as "unused" forever. Whitelist or accept the noise; don't chase them.
• "Unused" ≠ deletable. Before removing a flagged key, grep the whole repo including JS, emails, and PDF templates. Translation catalogs are frequently consumed outside the bundles the checker scans.
• Catalog format matters. YAML and XLIFF behave differently for nested keys and plural forms. If your project mixes formats across bundles, normalize or expect false mismatches.
• Exit codes are not guaranteed to be CI-friendly. Check whether the command returns non-zero on findings before you gate a pipeline on it — several 2015-era Symfony commands always exit 0.
• Clear the cache after config changes. app/console cache:clear -e=prod — DI config is compiled, and it's easy to spend twenty minutes debugging a path change that was never picked up.
• Run with -v early. Verbose output generally shows the parsed key list, which is the fastest way to prove the scanner is reading the directories you think it is.
• If the cost/benefit doesn't work out, the modern equivalent is a short script over symfony/translation catalogs plus lint:xliff / lint:yaml, or a maintained tool like Tolerance/TranslationToolsBundle-style extractors. The core check — "do all locales have the same key set?" — is ~50 lines of PHP and you own the false-positive policy.
• Extension points exist but are undocumented. If you need custom parsing logic, the services in Resources/config/services.yml can be overridden via services.yml / compiler pass — but verify against the actual class signatures, since there are no tests to lean on.