Language Command Laravel Package

Product Decisions This Supports

• Localization as a deploys-and-forgets capability, not a product feature. wp language core|plugin|theme install|update|list|is-installed turns "which translations are live, and are they current?" into scriptable, exit-code-addressable state. That lets us commit to "we ship in N locales" without building a translation delivery service.
• Roadmap input for internationalization. is-installed returning 0/1 makes locale coverage a measurable gate. We can define an acceptance criterion like "every locale in our supported list passes wp language * is-installed in staging" instead of relying on manual QA sign-off.
• Build vs. buy: buy (adopt). MIT-licensed, maintained under the official WP-CLI org, with Behat acceptance tests, PHPStan, PHPCS, and CI on every PR. The cost of replicating pack download, version-pinning to core/plugin versions, unpack, and cleanup is real and unglamorous; there is no differentiated value in owning it.
• Use cases this unlocks: provisioning new multilingual sites in CI; post-deploy translation refresh jobs; multisite network-wide locale rollouts via --all; baking translation packs into container images so production needs no outbound calls to downloads.wordpress.org; drift detection between plugin versions and their installed language packs.
• Deprecation signal to track, not act on yet. wp language core activate is deprecated in favor of wp site switch-language (a separate package). Any runbook or pipeline we write should target the new command so we don't inherit migration debt.
• Explicit non-decision: this is not a Laravel package. There is no service provider, facade, config publish, or runtime API — it is a WP-CLI command package installed into a WordPress/WP-CLI toolchain. It has no bearing on application-layer localization (Laravel's lang/ files, ICU messages, per-request locale negotiation). Do not let it into the app dependency graph.

When to Consider This Package

Adopt when all of the following hold:

• We operate one or more WordPress sites (self-hosted, Bedrock, or containerized) and already use WP-CLI in deploy or maintenance workflows.
• Locale coverage is an operational concern — agencies, multilingual marketing sites, multisite networks, or a headless WordPress backend serving a localized front end.
• We can tolerate the pack source being downloads.wordpress.org (or can pre-fetch in a build step and ship packs in the image).

Look elsewhere when:

• The product is Laravel/PHP application code. Use Laravel's own translation layer, or a TMS (Crowdin, Lokalise, Phrase) for content and string localization. This package does nothing for that.
• We need runtime, per-request locale negotiation or user-level language switching in a web request. That is wp site switch-language / WordPress core behavior, not this package.
• We require vendor support, SLAs, or a guaranteed API surface. 15 GitHub stars and a 0-dependent count are misleading in isolation (it ships inside the WP-CLI bundle), but there is no commercial backing — treat it as community infrastructure with a small maintainer pool.
• We are on managed WordPress hosting (WP Engine, Kinsta, Automattic) where WP-CLI access and pack installation may be restricted or abstracted; confirm before designing a workflow around it.
• We need translation of custom theme/plugin strings not distributed via WordPress.org. This only pulls published language packs; in-house strings need a separate pipeline.

Adoption risks to price in: network egress and availability of downloads.wordpress.org at deploy time; version-coupled pack URLs (packs are fetched per core/plugin version, so a plugin bump can silently orphan a translation until update runs); and CLI-only ergonomics — output is human-readable by default, so pipelines should use --format=json/csv and --dry-run rather than parsing tables.

How to Pitch It (Stakeholders)

To executives: This is free, MIT-licensed plumbing from the official WP-CLI project that lets us manage WordPress translations the same way we manage code — declaratively, in pipelines, with pass/fail signals. It converts "is the Dutch site actually in Dutch?" from a manual spot-check into an automated check, and it lets us add a locale to a rollout without a bespoke engineering project. Zero license cost, no new vendor, low lock-in.

To engineering: Add wp-cli/language-command to the WP-CLI toolchain, not the application. Wire three things: a --dry-run translation-update step in the deploy pipeline, an is-installed gate per supported locale in staging, and a --format=json drift report for observability. Prefer pre-baking packs in the container image for production so deploys don't depend on WordPress.org uptime. Use --all for multisite fleet operations. Write runbooks against wp site switch-language, not the deprecated wp language core activate.

To the team as a whole: It is a small, well-tested, single-purpose tool with a narrow blast radius. The main discipline required of us is scope: it handles WordPress-distributed language packs only, and it lives in ops, not in the Laravel codebase. Keep it there and the maintenance burden is near zero.