Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extract strings for translation from theme.json #254

Merged
merged 22 commits into from
Jul 19, 2021
Merged

Extract strings for translation from theme.json #254

merged 22 commits into from
Jul 19, 2021

Conversation

oandregal
Copy link
Contributor

@oandregal oandregal commented Jun 21, 2021

Closes #224

Setup

  • See https://make.wordpress.org/cli/handbook/contributions/pull-requests/#setting-up
  • To run the behat tests you also need a working mysql locally:
    • Install the packages if you don't have them. In linux: sudo apt install jq mysql-server mysql-client php-mysql
    • composer install && composer behat => it didn't setup the database for me (mysql 8) so I did;
      • sudo mysql -u root
      • CREATE DATABASE IF NOT EXISTS wp_cli_test;
      • CREATE USER 'wp_cli_test'@'localhost' IDENTIFIED WITH mysql_native_password BY 'password1';
      • GRANT ALL PRIVILEGES ON wp_cli_test.* TO "wp_cli_test"@"localhost"

How to test

  • Check out this PR locally and cd to the directory.
  • composer install
  • Create a new directory called foo-theme and create a theme.json file within with the following contents:
      {
        "version": "1",
        "settings": {
          "color": {
            "palette": [
              { "slug": "black", "color": "#000000", "name": "Black" }
            ]
          }
        }
      }
  • Run vendor/bin/wp i18n make-pot foo-theme
  • Verify that there's a foo-theme/foo-theme.pot file and that the "Black" string is present as well as its context "Color name". You should see something like:
msgctxt "Color name"
msgid "Black"
msgstr ""

Stress test the network connection

Switch to offline and verify that the file is still generated properly using the local file. Upon executing the command, you should see the following message:

PHP Warning:  file_get_contents(): php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in /home/andres/src/i18n-command/src/ThemeJsonExtractor.php on line 106
PHP Warning:  file_get_contents(https://github.com/WordPress/gutenberg/wp/trunk/lib/experimental-i18n-theme.json): failed to open stream: php_network_getaddresses: getaddrinfo failed: Temporary failure in name resolution in /home/andres/src/i18n-command/src/ThemeJsonExtractor.php on line 106
Success: POT file successfully generated!

@@ -0,0 +1,51 @@
{
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ideally, wp-cli would take this file from the WordPress core if it exists. If it doesn't, it shouldn't lookup for strings in the directory, as it means that the WordPress version in use doesn't support theme.json.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that wp i18n make-pot is usually run against a single theme's directory, with no knowledge of a WP installation around it.

Ideally the theme-i18n.json file is requested from an external API, e.g. WordPress.org, based on the version field in the theme.json file.

It shouldn't be bundled with WP-CLI for sure.

BTW, the same would need to be done for block.json.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As per #224 (comment) by @schlessera my understanding is that we want to access this from WordPress core. What would be the preferred way to do so?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(same as below, didn't see Pascal's comment when posting mine because I hadn't reloaded the browser)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It may take a bit to create and deploy an endpoint in wordpress.org. Would you think it's reasonable to bundle this file with 2.5.1 so we then can update translate.wordpress.org for these strings to be translatable for the WordPress 5.8 release? We can work on that endpoint later, with more time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In 6d850a1 I'm pulling the file from Gutenberg's GitHub repo. I've also added a fallback to the local file if there was an issue and it is empty. I've tried using WordPress.org SVN but it reports a 403.

If this unblocks us to ship this, let's do it. My preference, however, would be to start only with the local file as it less fragile.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added some stress testing instructions in the description.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree with @nosolosw that for the first version a bundled schema file should only be used to not depend on an unstable URL like it's implemented right now. It's unstable because there's no version at all. In case there's a change to the structure of the file or the file is moved we'd have to update WP-CLI anyway right?
I don't think it's responsible to block/delay the command from working in this case just because a not yet published update isn't supported.

A compromise might be to add a --prefer-local-schema argument which can be used by environments which require a stable behaviour?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@schlessera Any thoughts on a --prefer-local-schema argument?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ocean90 Sounds useful, especially if it accepts a file path (which would default to the included one). This would let you easily experiment with different schema.

src/ThemeJsonExtractor.php Outdated Show resolved Hide resolved
@oandregal oandregal marked this pull request as ready for review June 21, 2021 11:12
@oandregal oandregal requested a review from a team as a code owner June 21, 2021 11:12
src/ThemeJsonExtractor.php Outdated Show resolved Hide resolved
src/ThemeJsonExtractor.php Show resolved Hide resolved
*
* @return mixed The value from the path specified.
*/
private function array_get( $array, $path, $default = null ) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We might want to move those utils to https://github.com/wp-cli/wp-cli or at least extract them to a new abstract class so it can be used by BlockExtractor

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to create a class for this to be available in other places. I don't see any potential use of them in BlockExtractor, though, so perhaps we can extract them when we need them?

@oandregal
Copy link
Contributor Author

@swissspidy @schlessera do you think this is ready? The only bit under discussion is whether the theme-18n.json can be bundled with this command until we find a better path forward.

@oandregal
Copy link
Contributor Author

@swissspidy @schlessera what would be the next steps for this? Anything I can do to move things forward?

@swissspidy
Copy link
Member

I'd love to get some additional feedback from @schlessera

Once merged, it would be good to follow up with another PR to improve the block.json extractor in similar fashion, re-using some of the code.

Comment on lines 152 to 154
// Using the WordPress.org SVN repo resolved to a 403.
// $file_structure = self::read_json_file( 'http://develop.svn.wordpress.org/trunk/src/wp-includes/theme-i18n.json', $context );
$file_structure = self::read_json_file( 'https://github.com/WordPress/gutenberg/wp/trunk/lib/experimental-i18n-theme.json', $context );
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://github.com/WordPress/wordpress-develop/master/src/wp-includes/theme-i18n.json?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've used the one in the wp/trunk branch because that's the one that only changes with WordPress core. I wish I could have used wp/5.8 but that branch is not created until WordPress 5.8 is released like WordPress.org's SVN.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So https://github.com/WordPress/wordpress-develop/5.8/src/wp-includes/theme-i18n.json perhaps?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Locking it to 5.8 doesn't help at all, then it can just as well be statically committed here. The idea of an outside source is about getting the changes from Core without needing to release another WP-CLI version in sync. If you lock the version that WP-CLI looks for, there's not much of a point.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It should be either:

  1. always retrieve the translation info for the latest development version: or
  2. always retrieve the translation info for the latest stable version.

Any other version is basically the same as having a hard-coded version inside of WP-CLI.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you share more details about what type of changes wouldn't work and why can't we make them work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any structural change to theme.json can affect this. A few ones I can think of right now: translatable strings need to be part of a leaf node that is an unkeyed array, the format supports variability in node names encoded via * but only to one level, can't translate several strings from the same leaf, etc.

It's not that these are planned changes. My point is that, in the current state of things, the unit that best encapsulates the behavior is the file + the code used to parse it. Hence, pulling the file from elsewhere is risky: can work with some changes, and won't work with others.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hi @schlessera is there anything I can help with to move this forward?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at the moment. I'll try to find the time to do a thorough final review, and then it will be good to be merged.
What I'll be looking at most of all, is ways in which this can break if the format changes, and ensure we have graceful handling for such cases (instead of causing a fatal or - even worse - succeeding with the wrong output).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to push changes to this PR if you want to. I'm also happy to add more graceful handling if we come up with anything.

@oandregal
Copy link
Contributor Author

oandregal commented Jul 8, 2021

@schlessera @swissspidy I wanted to share that the last fortnight of July (15th onwards) I'll have very limited availability. JFYI so you know what to expect from me in terms of time to respond/help/feedback/etc. You are very welcome to own this PR, should I not be around.

@youknowriad
Copy link

Hi folks, what's the status for this one, do you think we're still on track to land this in 5.8?

src/ThemeJsonExtractor.php Outdated Show resolved Hide resolved
@swissspidy
Copy link
Member

Hi folks, what's the status for this one, do you think we're still on track to land this in 5.8?

Just awaiting final review from @schlessera

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Extract translatable strings from theme.json files
6 participants