Load requested language by URL

[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 think it would be easy to read the language in the plugin-directory plugin. But what would the above URL have to look like for playground to automatically load a requested language?

Example: https://de.wordpress.org/plugins/external-files-in-media-library/ - always loads in an English environment.

[brandonpayton]

Thank you for for reporting this, @threadi. We probably should support a query param for language/locale.

[bgrgicak]

We could use the language query parameter to set the language.

[threadi]

Thanks for the tip. Unfortunately, the parameter does not work for the call that would be initiated.

Example: https://playground.wordpress.net/?plugin=external-files-in-media-library&language=de_DE&networking=yes&blueprint-url=https://wordpress.org/plugins/wp-json/plugins/v1/plugin/external-files-in-media-library/blueprint.json?rev=3141102

Even without networking=yes it does not work (although this is already set within the blueprint.json.

[brandonpayton]

We could use the language query parameter to set the language.

Thanks for pointing this out, @bgrgicak 🙇 .

@threadi, it turns out that mixing other Playground query params with a blueprint_url argument is not guaranteed to work because the Blueprint takes precedence. But there is a setSiteLanguage Blueprint step that can be used instead.

Here is an example of your external Blueprint adapted to use this step: Example in the Blueprint Builder

[threadi]

I know about the options in blueprint.json, they are not the problem. Please take another look at my initial question. The issue is that when you click on “Live-Preview” on the plugin pages via the code stored in https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-template.php?rev=12931#L734, you are currently not redirected to the playground in a language-specific manner. The transfer of the language parameter for language-specific plugin pages to the playground is missing here. As written, it will certainly be possible to read out the language. The question is how to use this language to load the playground in the language the user is using.

A plugin on the Spanish pages should load the Spanish backend in the Playground during “Live-Preview”. A plugin on the German pages should load the German backend in the Playground for “Live-Preview”.

If it were possible to access an HTTP request parameter in blueprint.json to read the language parameter from the URL, you could perhaps use setSiteLanguage. But since it is a JSON and not a PHP file, I don't see any chance of that.

What would have to be done to enable the Playground to do this?

[carstingaxion]

I was looking for a way to do the same; so I agree absolutely in the need for a language query param that is compatible with a blueprint-url param.

I would love to run a Playground in a matrix of locales, as a Github actions workflow to generate screenshots of a plugin for the w.org repository. The possibility to set the language from outside the blueprint.json is the last missing puzzle-piece in GatherPress' migration from wp-env to wp-playground/cli for generating its screenshots.

[carstingaxion]

For now, I solved this by merging a dynamic setSiteLanguage step into my blueprint. This works fine in a workflow like so:

  - name: Prepare localized blueprint
    # en_US should not get any additional steps added, as this will result in errors!
    #
    # All other locales need this step!
    run: |
      if [ ${{ matrix.locale }} == 'en_US' ]; then
        cp .github/scripts/wordpress-org-screenshots/blueprint.json localized_blueprint.json
      else
        language_step='[
          {
            "step": "setSiteLanguage",
            "language": "${{ matrix.locale }}"
          }
        ]'
        echo "Use jq to append the site language step to the existing blueprint JSON file."
        jq --argjson languageStep "$language_step" '.steps += $languageStep' .github/scripts/wordpress-org-screenshots/blueprint.json > localized_blueprint.json
      fi

  - name: Starting Playground
    # The "&" is important to allow the next step to start!
    run: |
      ./node_modules/@wp-playground/cli/wp-playground.js server --blueprint=./localized_blueprint.json &

[brandonpayton]

I know about the options in blueprint.json, they are not the problem. Please take another look at my initial question. The issue is that when you click on “Live-Preview” on the plugin pages via the code stored in...

The question is how to use this language to load the playground in the language the user is using.

Sorry, @threadi, I see now.

I don't have time left today but made added this to my list for tomorrow.

If it were possible to access an HTTP request parameter in blueprint.json to read the language parameter from the URL, you could perhaps use setSiteLanguage. But since it is a JSON and not a PHP file, I don't see any chance of that.

I was thinking about something similar: What if we added support for Blueprint arguments?

Blueprints could declare argument names, types, and default values. Then we could either support text replacement or (probably much better) a structured way to express variable interpolation throughout the Blueprint.

^ @adamziel, @bgrgicak, and @dmsnell, do you have any thoughts on this?

[bgrgicak]

Blueprints could declare argument names, types, and default values. Then we could either support text replacement or (probably much better) a structured way to express variable interpolation throughout the Blueprint.

This sounds interesting but could add a lot of complexity. There is something nice about having a static JSON file that we can just read and the user can always expect the same result.

Would it work if query strings would override blueprints? In this example, we could swap the setSiteLanguage step value while building the blueprint if we detect a language query string. This would make the blueprint dynamic without the extra complexity that variables would add.

[threadi]

In the meantime I also had another idea (or 2) which doesn't concern the Playground but wordpress.org. The link containing the path to blueprint.json is generated at https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-template.php?rev=12931#L734.

Idea 1: language-specific blueprints.json at wordpress.org. Each plugin developer could provide these separately and thus ensure a switch themselves. There are certainly plugins that are fixed to one 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 the blueprint.json (which would not be possible with the idea developed here so far).

Idea 2: 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 saved somewhere and somehow.

Both would relieve you of the burden, but I still see major issues with both ideas that need to be clarified “over there”. I'll create a ticket there in the next few days. From my point of view as a plugin developer, my idea 1 would currently be the preferred way and would also take the work off your hands ;)

[adamziel]

The easiest solution here would be what @bgrgicak proposed – to still apply the language query arg even when the Blueprint is provided, as long as the Blueprint contains no setSiteLanguage step. I'd just hold off with that until https://github.com/WordPress/wordpress-playground/pull/1731 lands as it profoundly changes the state management logic and I'd rather avoid building that feature twice.