Live-Preview: load Playground in actual language

[threadi]

The path from international WordPress plugin sites to the Playground is currently still somewhat confusing. If you click on a live preview button on ​https://de.wordpress.org, for example, you always end up in an English environment - not the German one.

Currently, the plugin-directory plugin calls this URL from the Playground, regardless of which language is actually used:

https://playground.wordpress.net/?plugin=%s&login=1&url=%s

Source: https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-template.php?rev=12931#L734

---

I have 3 ideas for optimizing this:

a) Call up the playground with a language parameter at the above mentioned source. I have already opened an issue in the Playground group on github, but I think it might be too complex to parameterize a JSON file: ​https://github.com/WordPress/wordpress-playground/issues/1703 - it would also not be as flexible as the following idea.

b) Introduction of language-specific blueprints.json at wordpress.org. Each plugin developer could provide these separately and thus ensure a conversion themselves. There are certainly plugins that are fixed to a region of the world with a specific language, which would then have everything in their hands. They could then also provide individual language-specific content that they define in their own language-specific blueprint.json (which would not be possible with idea a)). This would also be analogous to the procedure with screenshots, which can also be language-specific. I could imagine storing the language-specific blueprints.json in subdirectories in the SVN:

/assets/blueprints/blueprint.json
/assets/blueprints/en/blueprint.json
/assets/blueprints/es/blueprint.json
/assets/blueprints/fr/blueprint.json

If this were basically possible, one would only have to define which language abbreviations are allowed ("de_AT", "de_CH-informal" ..).

c) wordpress.org could generate a language-specific file from the basic blueprint.json and pass it on to the Playgroud. The challenge here is that such files must also be stored somewhere and somehow.

---

At the moment I think that b) would be the best option. I would be happy to read the opinions of those who are most familiar with the technology involved at wordpress.org :)

[tellyworth]

Thanks for the ideas @threadi!

b) Introduction of language-specific blueprints.json at wordpress.org.

The potential for multiple language-specific blueprints is one of the reasons I put blueprint files in a separate subdir. There's as-yet-unused code in place to detect and import multiple blueprints, but it doesn't yet commit to any particular use case.

I'd hesitate to go with this solution though unless there are compelling benefits. If it turned out there were other useful dimensions for multiple blueprints (for different plugin versions, or different preview types, say) then we'd very quickly multiply the number of blueprints by some number of languages and create an unsustainable mess.

c) wordpress.org could generate a language-specific file from the basic blueprint.json
The challenge here is that such files must also be stored somewhere and somehow.

Here's where I have good news!

Plugin blueprint.json files aren't served directly, for CORS and performance reasons. They're stored in postmeta and output by a REST API endpoint:

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/api/routes/class-plugin-blueprint.php#L30

This means we have the opportunity to automatically add a step or property to the blueprint on-the-fly. It would be easy enough to pass the locale through to the API so it knows what option to add.

At a quick glance I don't see an obvious blueprint property for setting the language, even though there is one in the query API. Do you happen to know if there's a blueprint property for it? (If not I guess we can add a siteOptions step).

It shouldn't be too difficult to work up a quick patch for the REST API and preview button.

[dd32]

Replying to tellyworth:

At a quick glance I don't see an obvious blueprint property for setting the language, even though there is one in the query API. Do you happen to know if there's a blueprint property for it? (If not I guess we can add a siteOptions step).

I think you want the setSiteLanguage step

[tellyworth]

First draft patch - working ish

[tellyworth]

I attached a draft patch that seems to work, but hasn't been extensively tested.

In particular, it doesn't do any real validation of the language/locale string. I'm not sure how much is needed.

[dd32]

Replying to tellyworth:

In particular, it doesn't do any real validation of the language/locale string. I'm not sure how much is needed.

I don't think anything is really needed here, as long as it's a string, we can just palm validation off to Playground.

[tellyworth]

@threadi here's an example of what the blueprint.json looks like with setSiteLanguage automatically injected by that patch:

{
  "landingPage": "/wp-admin/admin.php?page=personioPositions",
  "preferredVersions": {
    "php": "8.2",
    "wp": "latest"
  },
  "features": {
    "networking": true
  },
  "steps": [
    {
      "step": "setSiteLanguage",
      "language": "de_DE"
    },
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "runPHP",
      "code": "\u003C?php require_once 'wordpress/wp-load.php';update_option( 'personio_sqlite', '1' );"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "personio-integration-light"
      },
      "options": {
        "activate": true
      }
    }
  ]
}

Would that solve the issue? Do you forsee any other unintended consequences? (Note that the patch should skip adding the step if the blueprint already includes setSiteLanguage).

[threadi]

Looks good in principle. Interesting that you use one of my plugins as an example ;)

setSiteLanguage should come after installPlugin, because in the Playground setSiteLanguage also triggers the installation of the language files of installed plugins. I have just tested this successfully. Like this:

{
  "landingPage": "/wp-admin/admin.php?page=personioPositions",
  "preferredVersions": {
    "php": "8.2",
    "wp": "latest"
  },
  "features": {
    "networking": true
  },
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "runPHP",
      "code": "<?php require_once 'wordpress/wp-load.php';update_option( 'personio_sqlite', '1' );"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "personio-integration-light"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "setSiteLanguage",
      "language": "de_DE"
    }
  ]
}

I think the entry should come at the end of the array - or at least after installPlugin.

[tellyworth]

Well I had to use something as a sample to test :)

Thanks for that insight, that's a great point about putting it as a later step. I think I'll just move it right to the end, that's easiest.

Will get a fresh patch up for review soon.

[threadi]

Just one more thought: where does the installPlugin step come in the blueprint? This is not added at wordpress.org but by the Playground? And there presumably at the end of the steps? In your example here, you added it manually to test the process. If this is the case, this addition would be useless here, as the language is then set BEFORE the plugin is installed when the steps are executed.

In this case, what @zieladam has postulated here would be more helpful: ​https://github.com/WordPress/wordpress-playground/issues/1703#issuecomment-2343466381 - as soon as the Playground supports this, you would just have to add language as a parameter to the playground-URL and not adapt the blueprint.json.

[tellyworth]

Put the lang step last; also bypass for en_ locales

[tellyworth]

The installPlugin step is added dynamically by the plugin directory when the blueprint.json file is imported, if the blueprint doesn't already include one:

https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/cli/class-import.php#L1275

I updated the patch with a new version that puts the setSiteLanguage last. Also fixed a bug with en locales. This should work ok I think? -

{
  "landingPage": "/wp-admin/admin.php?page=personioPositions",
  "preferredVersions": {
    "php": "8.2",
    "wp": "latest"
  },
  "features": {
    "networking": true
  },
  "steps": [
    {
      "step": "login",
      "username": "admin",
      "password": "password"
    },
    {
      "step": "runPHP",
      "code": "\u003C?php require_once 'wordpress/wp-load.php';update_option( 'personio_sqlite', '1' );"
    },
    {
      "step": "installPlugin",
      "pluginZipFile": {
        "resource": "wordpress.org/plugins",
        "slug": "personio-integration-light"
      },
      "options": {
        "activate": true
      }
    },
    {
      "step": "setSiteLanguage",
      "language": "de_DE"
    }
  ]
}

[threadi]

Yes, it looks great like this @tellyworth :) I'm still a bit annoyed that the posts and pages aren't in German, but that's because the Playground generally installs the English WordPress package, which you can currently only change with the language parameter in the URL, but that currently causes the blueprint.json to be ignored.

I think your customization is therefore only the first step, because as soon as the customization Adam mentioned here ​https://github.com/WordPress/wordpress-playground/issues/1703#issuecomment-2343466381 is in the Playground, you can set the language via the language parameter at the Playground URL. We'll have to see how that works when the time comes. But your customization here could be very helpful for many users until then :)

[tellyworth]

Thanks @threadi! I want to do some regression before I deploy it, should get to that soon.

[tellyworth]

In 14075:

Plugin Dir: use locale for Live Preview button.

This carries the user's current locale through to Playground when using the Live Preview button in the plugin directory. A setSiteLanguage step is automatically added to the plugin's blueprint.json file if not already present.

See #7769.

[tellyworth]

I think we can close this now unless there are immediate further updates needed. If the Playground side changes we can consider that a new ticket.

[threadi]

Yes, that's what we do. Thank you for your assistance with this request :-)