Gettext Translation Bundle Laravel Package

Product Decisions This Supports

• Localization architecture: build vs. buy the translation plumbing. This package is a thin adapter that swaps Symfony's file-parsing translator for PHP's native gettext extension (compiled .mo files, memory-mapped lookups). The PM decision it informs is whether translation lookup cost is worth engineering effort at all — the honest answer for most products is "no, until translation volume and locale count make per-request file parsing measurable."
• Performance-vs-maintainability trade-off on the i18n layer. Native gettext is genuinely faster than parsing XLIFF/YAML/PHP arrays on every request, and .mo files are the lingua franca of translation tooling (Poedit, Crowdin, Lokalise, Weblate all export them). Choosing this shape means committing your content pipeline to PO/MO as the source of truth — a decision that ripples into vendor selection, translator workflows, and CI.
• Framework-fit check. Despite the framing, this is a Symfony bundle, not a Laravel package — no service provider, no config/app.php entry, no Laravel translation loader integration. A PM scoping a Laravel roadmap should treat this as a non-candidate and instead evaluate gettext/gettext (pure-PHP, no extension requirement) or Laravel's native lang/ files. Flag the mismatch before an engineer spends a sprint proving it.
• Use cases where the value proposition is real: high-traffic read-heavy pages with 10+ locales, content-heavy marketing/CMS surfaces where copy is edited by non-developers in PO tooling, and legacy Symfony 2/3/4 applications already shipping .mo files where rewriting the translation layer has no user-visible upside.
• Roadmap signal, not a roadmap item. With 24 stars, zero dependents, and a last release of February 2018, this is effectively an abandoned internal utility that LeaseWeb open-sourced. It informs a "do not adopt" decision and, at most, a 1–2 day spike to benchmark native gettext against your current translator before deciding the perf gap is irrelevant.

When to Consider This Package

Consider it only if all of the following hold:

• You are on Symfony (not Laravel), on a PHP/Symfony version pair that predates the 2018-era constraints — practically Symfony ≤4 and PHP ≤7.x. On PHP 8.2+ or Symfony 6/7, expect breakage and no upstream fix.
• The gettext PHP extension is guaranteed present in every environment. It is absent by default in many official Docker images, Alpine builds, and most shared hosting — a deployment risk you now own.
• Your app runs on classic PHP-FPM with one request per process. Native gettext relies on setlocale(), which is process-global, not request-scoped. Under Swoole, RoadRunner, FrankenPHP worker mode, or Laravel Octane, concurrent requests in different locales will leak each other's translations. This alone disqualifies it from most modern runtime targets.
• You already have, or are willing to build, an automated PO↔MO compile step in CI — hand-editing .mo is not viable, and stale compiled catalogs are a silent, user-facing failure mode.
• You accept vendor abandonment: you are buying a ~200-line adapter you must fork and maintain. Budget for that explicitly, or don't start.

Look elsewhere if: you're on Laravel (use native lang/ files or gettext/gettext); you need ICU MessageFormat plurals/gender/select (Symfony's intl-icu domain or a managed TMS wins); you want per-request locale isolation and long-running workers; you need active security patching; or your translation volume is small enough that lookup cost is noise. Also look elsewhere if you want translator UX — a TMS (Crowdin, Lokalise, Phrase) with an API-driven pull gives you PO/MO and workflow, which is the actual product problem.

How to Pitch It (Stakeholders)

To executives: "We evaluated an open-source gettext adapter for our translation layer. It offers a real but narrow performance win by using PHP's compiled-in gettext support instead of parsing translation files on every request. However, it's a Symfony-only component that hasn't been updated since 2018, has no downstream users, and is incompatible with our planned long-running worker architecture because PHP's gettext stores locale globally per process — meaning two users in different languages could see each other's text. Recommendation: do not adopt. We get the same performance profile from a maintained pure-PHP library, or by caching our compiled translation catalogs, at a fraction of the operational risk."

To engineering: "This is a Symfony bundle wrapping the native gettext extension — no Laravel support, so it's out of scope for our stack. Two technical blockers worth recording in the decision log: (1) setlocale() is process-global, so it breaks under Octane/Swoole/RoadRunner; (2) the extension isn't installed in our base images, adding a build-time dependency for a ~1–2ms/request gain. If we want PO/MO as our translation format, the maintained path is gettext/gettext with a compile step in CI, or a TMS that exports .mo and a cached loader. Either way, the format decision — not this package — is the one worth a spike."

Framing for the decision log: the reusable insight is that translation format choice (PO/MO vs. ICU vs. flat files) is a product/vendor decision, while the loader is an implementation detail. Pick the format for tooling and translator workflow; pick the loader for runtime safety. This package conflates the two and is stale on both axes.