Motranslator Laravel Package

Product Decisions This Supports

• Localization roadmap sequencing. Choosing an MO/Gettext-based translation layer determines how locales ship: .mo files are compiled artifacts, so each locale becomes a discrete, testable release candidate. That turns "launch locale #4 in Q3" from an engineering project into a content-and-ops task with a clear definition of done.
• Build vs. buy on i18n plumbing. The genuinely hard parts — MO binary parsing, plural-form equations without eval(), context-aware lookups — are already solved. This lets us decide not to build a translation runtime and redirect that capacity to product surfaces.
• Deployment and infrastructure constraints. It removes the native PHP gettext extension as a hard dependency. That is a product decision when shipping to minimal containers, managed PHP runtimes, or environments where enabling an extension is a support ticket. It also sidesteps the long-standing MO-file-caching segfault, which unlocks "update translations without a restart" — a real operational capability for urgent copy fixes.
• Whether pluralization and context are requirements, not nice-to-haves. ngettext/npgettext support means the roadmap can credibly target locales with 3–6 plural forms (pl, ru, ar) and can disambiguate short UI strings ("Post" as noun vs. verb). If those markets are in scope, a naive key→string JSON store with {count} interpolation is not equivalent, and this becomes a differentiator rather than a detail.
• Runtime string override as a product capability. setTranslation/setTranslations allows correcting copy, supporting white-label/tenant-specific terminology, or letting admins edit strings without a deploy. Whether we want that feature is a product call; this package makes it cheap.
• Performance and cost envelope. The default in-memory cache is per-process memory; the APCu-backed cache shares translations across processes and approaches native gettext performance. That is the input for deciding whether i18n is a meaningful line item in our memory/instance budget at scale.
• Translator tooling and vendor lock-in. MO means translators keep Poedit, Weblate, or Crowdin workflows. This decision keeps a TMS purchase optional rather than forced, and keeps the contributor funnel open.

When to Consider This Package

Consider it when:

• You already have (or will have) Gettext .mo catalogs — from a TMS, an existing non-Laravel PHP app, or a translation vendor export.
• You cannot rely on the native gettext extension being present or configurable, or you deploy to ephemeral/containerized infrastructure.
• You need to hot-swap translation files without a redeploy or restart.
• Context-aware strings (pgettext) and true multi-form plurals are requirements, not edge cases.
• You can pin a version, accept a GPL-2.0 dependency after legal review, and run on PHP 8.2+ (6.x). Add APCu if you have large catalogs or high request volume.

Look elsewhere when:

• GPL-2.0 is incompatible with your distribution model. This is the primary gate. GPL is generally manageable for a hosted SaaS, but distributing the product — including to on-prem customers or via an appliance — triggers obligations. If legal has no appetite, stop here and use Laravel's native lang/JSON translator instead.
• Your translations live in PHP arrays or JSON and there is no MO source. Laravel's built-in translator is better supported, has no license friction, and integrates with __() out of the box.
• You need ICU MessageFormat (gender, select, nested plurals) rather than Gettext plural equations. Symfony Translation + ICU is the right shape for that.
• You need a translation management system, machine translation, per-user locale detection from browser/geo, or translation of user-generated content. This package is a reader only — it does no extraction (xgettext), no compilation (msgfmt), and no workflow.
• Your MO catalogs are large enough that you don't want them resident in memory and APCu isn't available.
• You require vendor support, an SLA, or a large maintainer base. Signal check: 62 stars, no recorded third-party dependents, and a changelog that reads as a single-org maintenance effort for phpMyAdmin's own needs. That's adequate for a narrow, stable utility but it is a bus-factor risk — plan to pin the version and keep a fork path.

How to Pitch It (Stakeholders)

Executives: This is a small, free, already-battle-tested translation component (it powers phpMyAdmin) that lets us add languages as content rather than as engineering projects. It also removes a server-configuration dependency that has historically blocked deploys, and it lets us correct copy in production without a release. No license cost. Two flags for the decision: it carries a GPL-2.0 license that needs a one-time legal check against our distribution model, and its maintainer base is small, so we should treat it as a pinned dependency with a fallback plan.

Engineering: composer require phpmyadmin/motranslator, PHP 8.2+, no gettext extension required, no eval() for plural equations (it depends on symfony/expression-language). It offers a low-level MoParser plus CacheInterface for custom caching, an object-oriented Translator, and an optional global-function shim for drop-in Gettext compatibility. ApcuCache is the production path for shared caching, with TTL and reload-on-miss controls. What we still own: wiring xgettext/msgfmt into CI, cache sizing and monitoring, and a fork contingency. GPL-2.0 and a small upstream mean we should not expect feature requests to land on our schedule.

One-line recommendation: Adopt for the narrow job it does — reading MO catalogs without the native extension — contingent on legal clearing GPL-2.0 and on a deliberate decision that Gettext-compatible translator workflows are the right long-term bet.