search

wp-cli / language-command

Installs, activates, and manages language packs.
MIT License
13 stars 21 forks source link

Not possible to install translations for en_US #84

Open ocean90 opened 5 years ago

ocean90 commented 5 years ago

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

https://github.com/wp-cli/language-command/blob/beedcd224040af410aea251aac121c0d30f5a185/src/WP_CLI/CommandWithTranslation.php#L251-L257

$ 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 commented 5 years ago

Sounds like a reasonable thing to fix 👍

vielhuber commented 5 years ago

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

swissspidy commented 4 years ago

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

maorweissSV commented 2 years ago

Is there an answer? How to change profile's language with cli..? image

swissspidy commented 2 years ago

@maorweissSV That's really unrelated to this ticket. But you can use wp user meta update 123 locale en_US to change the user's locale, assuming that the locale is installed. For further questions, please visit http://wp-cli.org/#support

maorweissSV commented 2 years ago

Ohhh... Sorry and thank you, @swissspidy

dottxado commented 2 months ago

Hello! I pick this 😄

dottxado commented 2 months ago

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 commented 2 months ago

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

https://github.com/wp-cli/language-command/blob/257b53623af088a6fa50b92a59a3b842b8a52601/src/Plugin_Language_Command.php#L280-L283

https://github.com/wp-cli/language-command/blob/257b53623af088a6fa50b92a59a3b842b8a52601/src/Plugin_Language_Command.php#L348-L352

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