Not possible to install translations for en_US

[ocean90]

CommandWithTranslation::get_installed_languages() currently assumes that translations for en_US are always installed.

language-command/src/WP_CLI/CommandWithTranslation.php

Lines 251 to 257 in beedcd2

	protected function get_installed_languages( $slug = 'default' ) {
	$available = wp_get_installed_translations( $this->obj_type );
	$available = ! empty( $available[ $slug ] ) ? array_keys( $available[ $slug ] ) : array();
	$available[] = 'en_US';
	return $available;
	}

$ wp language plugin install my-plugin en_US
Language 'en_US' already installed.
Success: Installed 0 of 1 languages (1 skipped).

But that's not always true. For example if you have a plugin which is by default provided in a different language than English. While translate.w.org doesn't support en_US as a locale, a custom implementation can support and hook into core filters to tell WordPress that there are translations for en_US.

Worth nothing that I can update en_US translation via WP-CLI once installed via wp-admin/network/update-core.php.

[swissspidy]

Sounds like a reasonable thing to fix 👍

[vielhuber]

Any progress on this? It seems that the fix is a oneliner.

[swissspidy]

@vielhuber PRs welcome :-) I haven't had time to work on this myself so far.

[dottxado]

Hello! I pick this 😄

[dottxado]

After working on this, I am not sure the solution to this issue lies in the portion of code highlighted.

WordPress Core defaults to en_US and the same convention is expected to be applied on themes and plugins, but it is not mandatory. What is described in the issue is an edge case, but nevertheless can happen and it has not an easy solution. I would like to investigate all the process of assigning the status to a language. In the meantime I have drafted a PR, but since I realized that, with that change, the en_US language transitions from active to uninstalled after another language is activated, I can't say I am trusting the solution.

[dottxado]

Hello again! I continue to confirm that this is an edge case out of the standard: gettext expects to be fed with English strings (see the homepage and the best practices).

I would like to ask to @danielbachhuber and @schlessera what should be the approach of the CLI here: rigid on the standard or not?

If not, the only solution I see (that's not the original PR I created) targets these sections of code

language-command/src/Plugin_Language_Command.php

Lines 280 to 283 in 257b536

	if ( in_array( $language_code, $available, true ) ) {
	\WP_CLI::log( "Language '{$language_code}' already installed." );
	++$skips;
	} else {

language-command/src/Plugin_Language_Command.php

Lines 348 to 352 in 257b536

	if ( in_array( $language_code, $available, true ) ) {
	\WP_CLI::log( "Language '{$language_code}' for '{$plugin_details['Name']}' already installed." );
	$result['status'] = 'already installed';
	++$skips;
	} else {

by adding to the command a --force flag to download the languages again. If it makes sense to you, I can prepare a PR.