- What is leaseweb/gettext-translation-bundle used for?
- It is a Symfony2-era bundle that adds native GNU gettext support for .po and .mo translation catalogs. It provides loaders, dumpers, and console commands to extract, update, and compile translations. It is not a Laravel package and does not integrate with Laravel's translator contracts.
- Does leaseweb/gettext-translation-bundle support Laravel?
- No, it is a Symfony bundle registered through the Symfony kernel and dependency injection container. It has no Laravel service provider, facade, publishable config, or Illuminate translation loader. Using it in Laravel would require writing a custom loader and locale middleware, at which point the bundle itself adds little value.
- How do I install and register LswGettextTranslationBundle in Symfony?
- It is installed with Composer and registered in the Symfony AppKernel as a bundle in Symfony 2/3 full-stack applications. Configuration is handled through the Symfony DI container rather than a Laravel-style config file. There is no Laravel installation path because there is no service provider.
- Which Symfony and PHP versions does LswGettextTranslationBundle support?
- The package targets the Symfony 2.8 to 3.x era, with its last release in February 2018. It is not compatible with modern Symfony 4.2+ translator changes, let alone Symfony 5, 6, or 7, without a rewrite. PHP 8 compatibility is unverified and unaudited.
- What do the bundle's .po and .mo loaders and dumpers do?
- The loaders let Symfony read gettext translation catalogs, while the dumpers write translation data back out. Console commands help extract, update, and compile .po files into binary .mo files. In practice, .po files are human-editable sources and .mo files are the compiled catalogs used at runtime by gettext.
- Is native gettext faster than Symfony's MoFileLoader?
- The bundle's core premise is to bypass PHP-level .mo parsing and delegate lookups to the native C gettext implementation, which can be faster. However, the gain depends on your request profile, translation volume, and locale setup, so it should be measured rather than assumed. Symfony's MoFileLoader is the proven fallback when native global state is unacceptable.
- Can I use native gettext with Laravel Octane, Swoole, or RoadRunner?
- Native gettext relies on setlocale and textdomain, which are process-global rather than request-scoped. In long-lived worker models, that shared state can leak between requests and create race conditions unless you carefully set and restore locale state per request. For Octane, Swoole, or RoadRunner, this is a major hazard and close to disqualifying.
- What OS requirements does native gettext add in production?
- You need ext-gettext enabled, the required LC_MESSAGES locales installed in every container image, and .mo catalogs compiled with msgfmt during CI or build. If locales are missing, translations can silently degrade to msgids. Managed hosting can make this a portability landmine because locale installation is outside application control.
- How should I test gettext translations in CI?
- Install gettext tools such as msgfmt, compile the .mo catalogs, and run integration tests with the target locale explicitly set. Cover plural forms, domains, fallback chains, and missing-catalog behavior rather than only simple string lookups. Native gettext state should also be reset between tests to avoid order-dependent failures.
- Is leaseweb/gettext-translation-bundle maintained, and what Laravel alternatives exist?
- The last release was in 2018, the project has very low adoption, and it is effectively a single-vendor, stale artifact. For Laravel, prefer native Laravel translations, a maintained package, or a small custom Illuminate loader if you truly need gettext-style catalogs. Pulling in a dead Symfony bundle for translation alone is not architecturally justified.