Weave Code
Language Command Laravel Package
wp-cli/language-command
A WP-CLI package for installing, activating, and managing WordPress language packs from the command line, covering core, themes, and plugins so you can add or update translations across your site quickly and consistently.
Installs, activates, and manages language packs.
Frequently asked questions about Language Command
- Is wp-cli/language-command a Laravel package?
- No. It is a WP-CLI bundle command that registers wp language core, wp language plugin, and wp language theme command classes through WP-CLI's package discovery mechanism and operates on a WordPress installation's filesystem and database. There is no service provider, facade, config file, or Laravel contract, so it should never be added to a Laravel application's composer.json as a runtime dependency. The only coherent use in a Laravel-centric estate is as operational tooling for WordPress instances, most commonly a headless WordPress CMS serving content to your Laravel app over REST or GraphQL. In that topology it belongs in the infrastructure layer and gets invoked from CI, deploy scripts, or an Artisan command that shells out.
- How do I install wp-cli/language-command?
- First check whether you already have it: modern WP-CLI commonly ships wp language as part of the bundle, and explicitly installing the package on top can create a duplicate-command conflict. If it is missing, run wp package install wp-cli/language-command, or add composer require wp-cli/language-command to a dedicated tooling repository alongside wp-cli/wp-cli-bundle. Every path requires a reachable WordPress root with wp-config.php, valid database credentials, and a writable wp-content/languages directory. That filesystem and credential coupling, not the PHP code, is the real integration cost.
- Can I run wp language commands from a Laravel Artisan command?
- Yes, but treat it as process orchestration rather than library integration. Create an Artisan command that invokes the wp binary through Symfony Process, pointing at the WordPress root with a working directory or the --path flag and passing --url for multisite contexts. Wrap the calls in idempotent scripts so reruns do not fail on already-installed packs, and check the exit code rather than parsing output strings. Keep the WordPress credentials in the environment of the deploy or tooling job, not in your Laravel app config.
- Which Laravel versions does wp-cli/language-command support?
- The question does not really apply, because the package has no Laravel dependency and no framework coupling whatsoever. Its constraints are the WP-CLI version you pin and the PHP version WP-CLI itself requires, both of which are independent of your Laravel version. As long as your Laravel app is only orchestrating the CLI through a process call, upgrading Laravel has no effect on this tool. If you are looking for a Composer package that plugs translations directly into Laravel's localization system, this is the wrong package.
- How do I install and activate a language pack for WordPress core, a theme, or a plugin?
- Use wp language core install nl_NL for core, wp language theme install twentyten nl_NL for a theme, or wp language plugin install hello-dolly nl_NL for a plugin. Each command downloads the matching zip from downloads.wordpress.org, unpacks it into wp-content/languages, and replaces any older translation. Activation for the site locale is done with wp site switch-language nl_NL rather than the older core activate subcommand. You can install several locales at once by listing them, which is useful for staging parity with production.
- Why does wp language core activate print a deprecation warning?
- The core activate subcommand has been deprecated in favor of wp site switch-language, so scripts written from older documentation will warn or break. Rewrite those calls as wp site switch-language with the target locale and the correct --url context for multisite. Review any deploy runbook or CI script that still uses the old verb, because deprecation warnings can become failures in future WP-CLI releases. It is worth grepping your tooling repo once rather than discovering it during a release.
- Does wp-cli/language-command work with WordPress multisite?
- It works, but the semantics require care: commands need the --url flag to resolve which site in the network you mean. A language pack installed for one site is not automatically installed or active network-wide, so installed here does not equal available everywhere. Decide explicitly whether your product requirement is a per-site locale or a network-wide default before writing the automation. Test the multisite path separately, because most published examples are single-site.
- Are language pack installs reproducible enough for production deployments?
- Not by default. Every install and update pulls from downloads.wordpress.org, language packs are mutable server-side, and there is no lockfile equivalent to pin a specific translation revision. For reproducible builds, bake the language packs into your container image at build time and treat wp-content/languages as immutable at runtime. For dynamic behavior, such as switching locale per site or request, keep the network dependency and add retries plus a fallback path. Also verify wp-content/languages is writable and persistent in your environment, since an immutable image will silently discard runtime installs.
- How is wp-cli/language-command tested and maintained?
- It is MIT licensed, stewarded by the WP-CLI organization, and ships with CI and code coverage badges plus Behat acceptance coverage for the commands. Release cadence follows conventional WP-CLI norms, and the project is maintained alongside the wider WP-CLI bundle. Adoption signals are thin, though: roughly 15 stars and zero dependents means little third-party battle testing outside WP-CLI itself. Validate the release metadata against the actual repository before planning around a specific version date, since the supplied details look future-dated.
- What are the alternatives to wp-cli/language-command?
- The most common answer is the wp language command already bundled with modern WP-CLI, in which case the correct action is writing scripts rather than adding a dependency. You can also install language packs manually through the WordPress admin under Settings and General, or manage files directly in wp-content/languages if you control the image build. If what you actually need is runtime multilingual content rather than core, theme, and plugin translations, look at dedicated plugins such as Polylang or TranslatePress instead. None of these replace a Laravel localization package, which solves a different problem.
Weaver
How can I help you explore Laravel packages today?