Language Command Laravel Package

Technical Evaluation

Architecture fit. The framing needs correcting before anything else: wp-cli/language-command is not a Laravel package and is not designed to be one. It is a WP-CLI bundle command — a set of WP-CLI command classes (wp language core|plugin|theme ...) that register themselves through WP-CLI's package discovery mechanism and operate on a WordPress installation's filesystem and database. There is no service provider, no facade, no Laravel contract, no PSR-compatible API surface. It is a CLI adapter over WordPress core's translation/language-pack machinery (Language_Pack_Upgrader, translations_api, switch_to_locale, and the wp-content/languages directory).

The only architecturally coherent way a Laravel-centric team leverages this is as operational tooling for WordPress instances in the same estate — most commonly a headless WordPress CMS serving content to a Laravel application via REST or GraphQL. In that topology the package belongs in the infrastructure/tooling layer, invoked from CI, deploy scripts, or an Artisan command that shells out via Symfony\Process. It should never appear in a Laravel app's composer.json as a runtime dependency.

Integration feasibility. High for the tool's actual job, low for the assumed job. Practical integration is one of:

1. Use the bundled wp language that ships with modern WP-CLI (verify first — it is commonly already present, and explicitly installing it can create a duplicate-command conflict).
2. wp package install wp-cli/language-command into the WP-CLI global composer project.
3. composer require wp-cli/language-command inside a dedicated tooling repo alongside wp-cli/wp-cli-bundle.

Every path requires a reachable WordPress root (wp-config.php, DB credentials, writable wp-content/languages). That filesystem/credential coupling — not the PHP code — is the real integration cost.

Technical risk. Code risk is low: MIT, WP-CLI org stewardship, CI and coverage badges, conventional release cadence, Behat acceptance coverage. Relevance and operational risk are the concerns:

Key questions for the discovery pass.

• Is there a WordPress installation in this product at all? If not, this evaluation terminates — there is no leverage.
• If yes, which WP-CLI version is pinned, and is wp language already bundled? If bundled, the correct action is "write scripts," not "add a dependency."
• Do Laravel UI locales and WordPress content locales need parity as a product requirement, or are they independent concerns owned by different teams?
• Is wp-content/languages writable and persistent, or is it baked into an immutable container image?
• Do we need reproducible builds (language packs baked at image build) or dynamic behavior (locale switched per request/site)?
• Who owns WordPress infrastructure — and therefore owns the runbook for this command?

Integration Approach

Stack fit. Treat this as infrastructure-as-code surface, not application code. Concretely: a tools/wp/ directory (or the WP deployment repo) containing pinned WP-CLI, pinned language-command, and thin idempotent wrapper scripts keyed by locale. The Laravel application's only touchpoint should be a narrow, named interface — e.g. an Artisan command wp:languages:reconcile {site} {locales*} that wraps the process call, or better, a queued job triggered post-deploy. Do not let controllers or domain services call wp directly; that leaks WordPress operational concerns into the Laravel domain model.

Migration path.

1. Inventory — enumerate WordPress instances, their WP-CLI version, PHP version, and current locale state (wp language core list --status=installed --format=json).
2. Confirm availability — run wp language --help against the pinned WP-CLI. If present, skip installation entirely.
3. Install if required — into the WP-CLI composer project only, with an explicit version constraint.
4. Wrap — write scripts that are idempotent, locale-driven, and use --format=json plus exit codes as the contract.
5. Relocate to build time — bake the default locale set into the container image so runtime has no external network dependency.
6. Add scheduled reconciliation — a nightly or weekly job that installs/updates and reports drift.

Compatibility. Four axes must be locked simultaneously: WP-CLI version ↔ language-command version ↔ PHP runtime ↔ WordPress core version. Language packs for plugins and themes are keyed to the installed plugin/theme version — a plugin update orphans its language pack until wp language plugin update runs, so the ordering of plugin updates relative to language updates matters. Multisite targets require --url on nearly every invocation. Command renames (core activate → site switch-language) must be codified in the wrapper so nobody reintroduces the deprecated form.

Sequencing.

• Phase 1 (1–2 days): bake default locales at image build; verify on staging. Zero runtime risk, immediate win.
• Phase 2 (1 sprint): on-demand install/switch via wrapper + runbook; is-installed used as a precondition check (exit 0/1 is a clean gate).
• Phase 3: scheduled reconciliation with --dry-run diffing before applying; list --status=installed compared against a declared desired-state manifest.
• Phase 4: alerting on drift and on update-available status, integrated into existing monitoring.

Operational Impact

Maintenance. Upstream maintenance is WP-CLI's problem, and they do it well — the package has a small, stable command surface and a mature test harness. Our maintenance burden is the wrapper layer and the version matrix, both of which are small but permanent. Budget a few hours per WP-CLI major bump plus a check whenever WordPress ships a translation-API change. This is the lowest-effort component in the WordPress tooling stack; the surrounding orchestration is where the maintenance actually lives.

Support. No commercial support. Escalation path is GitHub issues upstream, and with 15 stars and no dependents, there is no meaningful community buffer — realistically you fork or pin. Internal support ownership must land with the team that owns WordPress infrastructure. Handing this to the Laravel team without that ownership transfer is a predictable source of unresolved tickets.

Scaling. This is a deploy/ops path, not a request path, so throughput is not the concern. The concerns are fanout and egress: sites × locales × plugins grows multiplicatively, and /plugin install --all or /plugin update --all are blast-radius multipliers that should be discouraged in favor of explicit targets. Parallelism should be modest and rate-aware against downloads.wordpress.org. Job duration is the practical ceiling — a full locale reconcile across a large fleet is a slow, serial, network-bound task.

Failure modes to design against.

• Partial network failure mid-download leaving stale or incomplete pack files — scripts must be re-runnable and verify state afterward.
• Filesystem permission or disk exhaustion on wp-content/languages — container images with read-only filesystems will fail here silently-ish.
• Locale code typos — invalid codes must be validated up front against translate.wordpress.org codes, not discovered at runtime.
• Plugin/theme version drift — language pack silently orphaned after an update; the update-available column is your only signal.
• Deprecated command usage — core activate still runs but is on a deprecation path; standardize on site switch-language.
• Multisite scope confusion — applying to one site when the network was intended, or vice versa.
• False-green success — exit code 0 does not mean "current"; it means "the operation completed." Staleness detection must be a separate check.

Ramp-up. A competent Laravel/PHP engineer reaches working proficiency with the four or five commonly used commands in well under a day — the CLI is genuinely well-documented and the --format=json output makes it scriptable. The real ramp is WordPress domain knowledge: locale code conventions, the language-pack-to-plugin-version coupling, and multisite context rules. That is roughly 2–3 days of adjacent learning on top of the CLI. Plan one sprint to go from "manual commands" to "declared desired state, reconciled automatically," and assign that ramp to whoever owns WordPress, not to the Laravel product team.