[wp-trac] [WordPress Trac] #50732: Block Directory: Support installing blocks in languages other than English

[WordPress Trac]

#50732: Block Directory: Support installing blocks in languages other than English
--------------------------+---------------------
 Reporter:  ryelle        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  new
 Priority:  normal        |   Milestone:  5.5
Component:  Editor        |     Version:  trunk
 Severity:  normal        |  Resolution:
 Keywords:  needs-patch   |     Focuses:
--------------------------+---------------------

Comment (by dd32):

 I think it's worth noting that `wp.i18n` translations aren't the only
 problem that ideally needs to be solved here. In short:
  - Plugins that make use of `wp_localize_script()` or
 `wp_add_inline_script()` don't work
  - Plugins that depend upon other JS/CSS assets may not work (ie. Core-
 provided JS asset that isn't auto-enqueued on the editor screen, or, a
 non-editor-related JS script registered by the plugin)
  - By simply injecting CDN'd JS/CSS blindly that WordPress.org has
 provided for the block, it introduces a reliance upon the WordPress.org
 CDN even though the site has the files locally, a Content-Security-Policy
 header may even prohibit the CSS/JS loading, and in other cases, the
 WordPress.org CDN may be blocked by "network filters"
  - By having WordPress.org provide the assets, it limits the ability for
 other plugins to hook in / replace the API call to provide their own Block
 Directory implementations, while not impossible, it means they'd have to
 do a bunch of the work we're doing on WordPress.org in order to detect the
 Block assets ahead of time.

 With respect to the first two points, the blocks will work fine if added
 via Plugins -> Add New, or the page is reloaded after using the Block
 Installer.

 Ideally, WordPress.org would not need to provide the list of JS/CSS assets
 to load, as it should be defined in the `block.json` and Gutenberg would
 simply load the assets based on a script/style dependancy check, ie. using
 #48654.

 Given we're already performing an expensive operation (Installing a
 plugin) I don't think we need to be ''too'' concerned with speed, but
 rather for editor safety and aim for a seamless always-works solution.

 I'd like to propose a different option, instead of having WordPress.org
 provide the assets, instead of requiring the authors properly define their
 asset requirements in the `block.json`, and instead of reloading the
 editor after each Block install, instead we re-load the editor interface
 through a XHR request (HTML only) and inject any differences in loaded
 styles/scripts into the current editor screen. In my testing, this works
 well, although has slightly more latency.


 https://github.com/WordPress/gutenberg/pull/24117 is an attempt at doing
 exactly that:
  - Install Block
  - Request current page via XHR
  - Insert any stylesheets or JS (either external, or inline JS - ie.
 Translations) into the current document
  - Continue inserting the block.

 In my testing it adds a slight delay (~2s on my development machine), as
 it's another admin page view, but could be optimised in the future by
 treating this as a fallback only when the assets aren't defined in the
 `block.json`.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50732#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform