I18N Command Laravel Package

Technical Evaluation

Architecture fit — poor as a direct Laravel dependency. Despite being listed as a "Laravel/PHP package," wp-cli/i18n-command is a WP-CLI command bundle, not a Laravel package. It has no service provider, no facades, no publishable config, and no PSR-4 hooks into Laravel's translator. Its runtime contract is WP_CLI and WP_CLI\Utils, both of which only exist inside the WP-CLI bootstrap. It solves WordPress i18n extraction (wp i18n make-pot, make-json, make-mo, update-po) against WordPress's __(), _e(), _n(), _x(), and @wordpress/i18n conventions — none of which overlap with Laravel's lang/*.php + __() translator model. Net: valuable only where a WordPress surface actually exists in the product.

Integration feasibility — viable in three narrow patterns.

• Sidecar CLI invocation: install WP-CLI in a build container and shell out from an Artisan command via Symfony\Process, exchanging .pot/.po/.mo/.json artifacts through shared storage. Lowest-effort path, no PHP dependency coupling.
• Library extraction: depend on the underlying gettext/gettext extractor directly and write a Laravel-side adapter that registers Laravel's translation functions and Blade @lang/{{ __('…') }} patterns. This is the only route to a genuinely unified string catalog, and it is real engineering work (est. 2–4 weeks for a robust extractor plus Blade parsing).
• Monorepo/CI job: keep WordPress marketing site or headless WP in the same repo and run this command as an isolated CI stage, publishing artifacts to the translation platform. No runtime coupling to the Laravel app at all.

Technical risk — moderate, mostly organizational.

• Hard dependency on WP-CLI and a WordPress install context; cannot be installed and used standalone in a Laravel composer.json without pulling WP-CLI runtime assumptions.
• WordPress-specific extraction heuristics will silently miss Laravel idioms — highest-risk failure is silent under-extraction, not a crash.
• Output format (POT/PO/MO) is not consumed natively by Laravel; a conversion or dual-pipeline decision is unavoidable.
• Dependency surface (gettext/gettext, PHP parser components) can collide with Laravel's constraint matrix if not isolated in its own composer context or container.
• 122 stars understates real usage — the command ships bundled with WP-CLI, so GitHub stars are a poor adoption signal here. Last release date indicates active maintenance. MIT license is compatible with commercial use.

Key questions.

• Do we actually have a WordPress surface (plugin, theme, headless WP, marketing site) in scope, or is this being evaluated for a pure Laravel app? If the latter, the answer is "no."
• Is the goal shared translation memory across WP and Laravel, or just shipping WP translations?
• Which system is the source of truth for strings — the Laravel app or the WP admin?
• Is a wp binary permissible in our CI/build images, and who owns upgrading it?
• Do we need JS translation parity (make-json → @wordpress/i18n), and does our frontend use that runtime?
• What is our PHP version matrix, and does the pinned WP-CLI release support it?

Integration Approach

Stack fit — conditional. Fits cleanly adjacent to Laravel, not inside it. Recommended topology: Laravel app stays on its native translator; WP-CLI runs in a dedicated build image (wordpress:cli or a slim PHP image with WP-CLI installed); the Laravel app orchestrates via a queued Artisan command and never imports the package's classes. If the team insists on in-process use, vendor only the extractor library, never the command classes.

Migration path. No migration from Laravel's existing i18n is required or advisable — that would be a regression. Instead, treat this as an additive pipeline for WP-origin strings. Two-stage path:

1. Phase 1 (weeks 1–2): containerize WP-CLI, wrap wp i18n make-pot in an Artisan command, publish artifacts to object storage, wire into CI. Zero changes to Laravel's lang/ files.
2. Phase 2 (optional, weeks 3–6): if unified translation memory is a requirement, build the gettext/gettext-based extractor with Laravel + Blade function registration, and use the WP-CLI command output as a validation oracle to measure extractor parity before cutover.

Compatibility.

• Requires WP-CLI 2.x and PHP matching WP-CLI's supported matrix — verify against our pinned PHP before committing.
• Isolate in its own composer.json or container to avoid constraint conflicts with illuminate/*.
• Artifact formats: POT/PO are consumed by Crowdin, Lokalise, Transifex, Phrase — confirm our vendor ingests POT with wp-style context comments (_x context, plural forms) without loss.
• Blade/.php coexistence: the extractor must be told to exclude resources/views and vendor or it will produce noise.

Sequencing.

1. Confirm the WordPress surface exists and name its owner. Gate: no WP surface → terminate evaluation, recommend Laravel-native tooling.
2. Spike: run make-pot against the WP codebase in a container, measure runtime, string count, and false negatives.
3. Decide pipeline ownership (WP team vs. platform team) and source of truth.
4. Ship Phase 1 CI integration with artifact pinning and a diff check on the POT file.
5. Only then evaluate Phase 2 extractor unification, with a defined parity threshold before replacing anything.

Operational Impact

Maintenance — low code churn, non-trivial version discipline. The package is small and stable, but it rides WP-CLI's release train and PHP version support. Pin an exact version, own the base image, and schedule a quarterly upgrade review. The real maintenance cost is the glue: the Artisan wrapper, artifact storage, and any PO→Laravel conversion utility — budget ongoing ownership for that glue, not for the package.

Support — organizational gap risk. Maintained under the WP-CLI org with a small contributor base; there is no Laravel-ecosystem support channel. Expect to self-serve issues and read WP-CLI source for edge cases. Assign a named owner with WordPress familiarity; a Laravel-only team will not be able to triage extraction bugs efficiently.

Scaling — CI-bound, not request-bound. Runs are CPU- and memory-heavy on large trees (full-repo parsing plus JS scanning); a monorepo run in the tens of thousands of files can take minutes and hundreds of MB. Mitigate with path scoping (--include/--exclude), incremental runs keyed to changed paths, and caching. No runtime scaling concern — it must never execute on a request path.

Failure modes.

• Silent under-extraction — most dangerous; strings using Laravel idioms or dynamic construction are dropped without error. Mitigate with a string-count regression gate and spot-check diffs on every POT change.
• Non-zero exit on partial success — CI must treat any non-zero as a hard fail, not a warning.
• Environment drift — a wp binary present locally but absent in CI (or a different WP-CLI version) yields divergent catalogs. Pin the image tag.
• Domain/context collisions — --domain and --ignore-domain choices are sticky; document the decision once and enforce it in the wrapper.
• Blade parsing crashes or noise — keep Laravel view paths excluded by default.
• Artifact overwrite — a failed run that still uploads a truncated POT can poison the translation vendor. Upload atomically; never overwrite on non-zero exit.

Ramp-up — moderate, culturally more than technically. Basic operation (make-pot, make-mo) is a half-day for anyone who knows gettext. The friction is WordPress-specific knowledge: WP-CLI conventions, WP i18n function semantics, and PO header/plural-forms handling. Realistic estimate: 1–2 days for a developer to be productive in the containerized pattern; 2–4 weeks of engineering for the Phase 2 unified extractor. Translation-vendor and localization-ops stakeholders should be briefed early, since the POT artifact becomes a contract with them.