-
Notifications
You must be signed in to change notification settings - Fork 52
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
Extract strings for translation from theme.json #254
Conversation
src/theme-i18n.json
Outdated
@@ -0,0 +1,51 @@ | |||
{ |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
* | ||
* @return mixed The value from the path specified. | ||
*/ | ||
private function array_get( $array, $path, $default = null ) { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
@swissspidy @schlessera do you think this is ready? The only bit under discussion is whether the |
@swissspidy @schlessera what would be the next steps for this? Anything I can do to move things forward? |
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 |
src/ThemeJsonExtractor.php
Outdated
// 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://raw.githubusercontent.com/WordPress/gutenberg/wp/trunk/lib/experimental-i18n-theme.json', $context ); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://raw.githubusercontent.com/WordPress/wordpress-develop/master/src/wp-includes/theme-i18n.json
?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So https://raw.githubusercontent.com/WordPress/wordpress-develop/5.8/src/wp-includes/theme-i18n.json
perhaps?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be either:
- always retrieve the translation info for the latest development version: or
- 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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
@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. |
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 |
Closes #224
Setup
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
composer install
foo-theme
and create atheme.json
file within with the following contents:vendor/bin/wp i18n make-pot foo-theme
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: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: