Translation Bundle Laravel Package

Getting Started

Before anything else: this is a Symfony 2 bundle, not a Laravel package. There is no service provider, no facade, no config/translation-bundle.php. If you're coming from Laravel you will be reading Symfony 2 conventions (AppKernel, Resources/config/services.yml, DependencyInjection/Configuration.php) and adapting them mentally rather than dropping this in via Composer into a Laravel app. The realistic paths are (a) use it inside a Symfony 2.x project, or (b) mine it for ideas / lift specific classes into a Laravel-native translation workflow.

Minimal steps to evaluate it:

1. Read composer.json first — check the symfony/* version constraints and PHP floor. This tells you immediately whether it runs on any modern stack.
2. Open DependencyInjection/Configuration.php — that is the canonical source of truth for every option the bundle exposes.
3. Read Resources/config/services.yml (or *.xml) to see which services are wired and what they depend on.
4. Look at Command/ — most Symfony 2 workflow bundles ship their real value as console commands, and those read like pseudocode for how to use the bundle.
5. Check Resources/doc/ or the README for the intended lifecycle (extract → translate → import, or admin-driven editing).

Your first use case will almost certainly be one of: exporting translation catalogs (to XLIFF/YAML/CSV) for an external translator or TMS, re-importing the translated files, or providing a Sonata-style admin UI where non-developers edit messages.*.yml safely. Pick the flow that matches your existing Resources/translations/ layout and prove it on one small domain (messages+intl-icu, a single locale) before wiring it into CI.

Implementation Patterns

Composer / kernel registration (Symfony 2). Register in app/AppKernel.php under bundles, then expose config under app/config/config.yml. Do this on a throwaway branch — the bundle is EOL and you do not want it in a shared baseline until you've proven the extract/import loop on real locale files.

Extract → translate → import loop. The day-to-day pattern is a three-command cycle:

• extract keys from templates/controllers into a canonical catalog,
• hand that catalog (or a diff against the last exported snapshot) to translators,
• import the returned files back into Resources/translations/.

Diff against the previous export rather than re-exporting everything — that turns an unmanageable "translate 4,000 keys" ticket into "translate 37 new keys," which is what makes this usable for a real team.

Admin integration. If the bundle ships an editor, mount it behind your existing admin auth (Sonata, FOSUserBundle, or a custom firewall). Translators should edit in the admin UI; developers should never hand-edit catalogs that the bundle owns, or imports will conflict.

Porting the idea to Laravel. If you're a Laravel dev reading this for patterns, the same three-command cycle maps cleanly onto php artisan make:command TranslatableExtract / Import, writing to lang/{locale}/*.php or resources/lang/{locale}/*.json. The interesting parts to steal are the key-extraction regex/AST logic, the diffing, and the import merge strategy — not the Symfony wiring.

CI integration. Run extract and diff on every PR; fail the build if the source catalog drifts from the committed catalogs. That single gate prevents "someone added __('...') but never translated it" from accumulating for a year.

Gotchas and Tips

• Abandonment is the headline gotcha. Zero stars, zero dependents, Symfony 2 era. Expect PHP 5.5–7.0 idioms, no PSR-4 autoloading in the modern sense, no support for +intl-icu message domains, and no maintenance. Treat it as reference material or a one-time migration tool, not a dependency you pin in a long-lived project.
• Symfony 2 is EOL. Even if the bundle works, the framework around it is out of security support. Do not let "we need this bundle" be the reason a stack stays on Symfony 2.
• Config quirks. Symfony 2 bundles commonly ship two config layers — the Configuration.php tree (what you're allowed to set) and defaults baked into the DI extension. If an option "doesn't work," check whether the extension actually reads it before blaming yourself. bin/console config:dump-reference <alias> (if your Symfony version has it) is your fastest sanity check.
• Locale/catalog naming. Symfony 2 translation catalogs are domain.locale.format with no locale fallback metadata. If you have en_GB vs en mismatches, the bundle will happily treat them as separate catalogs and your import will produce duplicates. Normalize locale codes before any import.
• Debugging. When something fails silently, it's usually a DI wiring problem, not bundle logic. Dump the container (debug:container <service>) and check that the service is actually registered — a missing tag or a misnamed services.yml entry is the common culprit.
• Extension points worth checking. Look for event dispatchers or CompilerPass classes. Symfony 2 bundles of this vintage often expose a TranslationBundleEvents or similar that lets you hook post-extract / pre-import — that's the cleanest place to inject your own filtering (e.g. skip keys from vendored bundles).
• Don't commit generated catalogs blindly. If the bundle rewrites YAML with a different key order or quoting style than your codebase uses, you'll get thousand-line diffs on every run. Normalize output (or lock a formatter) before the first real import.
• Laravel translation. If your actual goal is Laravel i18n workflow, skip the bundle entirely and look at laravel-lang/publisher, localazy/*, or Phrase/Lokalise SDKs — they solve the same extract/import problem on a maintained foundation.