JavaScript I18N Meeting Summary: May 8th

After the blog post about JavaScript internationalization, we held a first meeting last Tuesday to discuss how we can improve client-side translation in JavaScript. This is a summary of the JS I18N chat from May 8th, 2018. (Slack log)

Topics

First, we talked about the introductory blog post and the feedback it received so far. While the post gives a great overview of the two main problems — extracting strings from JavaScript and loading the actual translations in a way that makes sense — there are many smaller problems attached to them that need to be tackled.

Thus, we started looking at the string extraction part and the problems which come with it:

  • Plugins bundle their assets in many different ways: minified, non-minified, using simple UglifyJS or multiple individual modules and more complex tools like webpack.
  • If WordPress.org does parse source files, which syntax (e.g. ES2015, ES2018, JSX, etc.) should be supported? WordPress.org needs to set clear boundaries and best practices for plugin and theme developers.
  • Larger plugins like Gutenberg only provide the minified build files on WordPress.org. How can strings be extracted from those?
  • Should such plugins be expected to do the string extraction part themselves and provide a POT file that GlotPress can import? Right now, this is not possible.

Multiple JavaScript I18N tools already exist, e.g. @wordpress/i18n, @wordpress/babel-plugin-makepot, and a WP-CLI i18n command. These can be used to test a new JavaScript string extraction process for individual plugins like Gutenberg and perhaps a dedicated testing plugin.

We then switched over to the other main problem: loading translations for use in JavaScript. Since any solution here as an impact on string extraction and delivering language packs, this ideally should be solved first. The problem areas here are:

  • Plugins can have multiple scripts that can be enqueued each on their own. Loading all translated strings even though you’re only enqueueing one small script handle would have a negative impact on performance.
  • Could performance be improved by caching translations using something like IndexedDB?
  • A script handle could be a minified JavaScript file that originally consisted of multiple smaller JavaScript modules, each containing some translatable string. How can we know which translations should be loaded for the resulting script handle?
  • Can we have a map of script handle => original JavaScript files or perhaps a way of saying “for script handle X, load strings in text domains Y and Z”. How would an implementation for this look like?
  • What if a bundled script contains some third-party components calling wp.i18n.__() with their individual text domain? How could this be handled?

At the end, there were still too many open questions and we figured it would be best to have a look at how other projects handle this in order to not reinvent the wheel.

Next Meeting

We will meet again on Tuesday, May 15th at 15:00 UTC in #core-i18n to further discuss especially the translation loading part.

#i18n

WordPress 4.9.6 Release Candidate

The release candidate package for 4.9.6 has been released and is now available for testing. Please help test the release candidate version to ensure the version works as expected.

This package contains 30 bug fixes since the beta. This brings the total number of bug fixes in 4.9.6 to 40 while the number of enhancements/feature requests remains at 34.

Even more than usual, we need testers to help polish this release. This version (4.9.6) introduces the first round of tools that help WordPress site owners and admins meet the new requirements for user privacy regulations.

The official 4.9.6 release is scheduled for Thursday, May 17th.

Bug Fixes

A full list of bugs fixed in 4.9.6 Release Candidate can be found on Trac. The tickets listed below are only those committed since the beta was released.

Customize

  • #43945 – Missing closing button tag in ‘Live Preview’ button

General

  • #43934 – Missing doc for the user_request_key_expiration filter
  • #43951 – Typos in `WP_Privacy_Policy_Content::get_default_content()`
  • #44016 – user_request_action_email_content filter hook documentation inaccurate
  • #43583 – Account for SimpleXMLElement and `ResourceBundle` in is_countable()

Privacy

  • #43964 – “Email Data” button text – Make it more clear that an export link is sent, not the whole data
  • #43920 – Use the terms erase / erasure instead of remove / removal for personal data
  • #43905 – Personal data export link does not work
  • #43913 – On sending the personal data export email, the request should be marked COMPLETED
  • #43922 – Data removal/erasure requests don’t get marked as “Completed” after erasure happens
  • #44015 – Add `id` attribute to each row of privacy post list tables
  • #43852 – Fix spacing on responsive for Use This Page button in Privacy Tools
  • #43966 – Prioritize the User group in Personal Data Exports to right below the About group
  • #43968 – Add Request Type into Confirmation Email Subject for GDPR
  • #44023 – Remove help tab from settings privacy until we have something helpful to say
  • #43908 – Export keeps generating new .zip files on Windows installations
  • #43970 – Add request type to the confirmation confirmation page – GDPR
  • #43973 – Email user once removal request completed – GDPR
  • #44040 – Potential PHP notice in wp_ajax_wp_privacy_erase_personal_data()
  • #43954 – Showing the privacy policy admin notice on all screens is intrusive
  • #43933 – Make the Privacy Policy page intro text shorter and more friendly
  • #43909 – Improve styling on personal data tables
  • #43967 – Admin emails after email confirmation don’t work for GDPR requests
  • #43961 – Privacy Policy popup covers collapsed admin menu
  • #43929 – Privacy pages: buttons should be buttons and other coding standards
  • #44031 – Add personal data export request ID to the wp_privacy_personal_data_export_file_created hook
  • #43980 – Consider outputting the suggested privacy policy content to a new page instead of a postbox
  • #44023 – Remove help tab from settings privacy until we have something helpful to say

TinyMCE

  • #43984 – Customize: JavaScript error when opening Text widget
  • #43969 – Custom themes will not work in TinyMCE 4.7

A full list of all changes in 4.9.6 can also be found on Trac.

#4-9-6 #maintenance #release

Dev Chat Summary: May 9th (4.9.6 week 6)

This post summarizes the dev chat meeting from May 9th (agenda, Slack archive).

4.9.6 planning

  • Thanks to all the contributors working on 4.9.6 so far, everyone has been doing a great job!
  • Planning on a final bug scrub tomorrow (May 10th) at 14:30 UTC then packaging the release candidate at 20:00 UTC
  • There are still 13 open bugs that need final testing and feedback. The delay was a difficult decision, but it is giving us the amount of time needed to fix all of these little bugs.
  • Majority of bug tickets actively being worked on in #gdpr-compliance
  • @allendav and proof reading volunteers are working on handbook content to help devs work with the new privacy tools. Those will be supplemented by dev notes ASAP.
  • Beta is still available for testing, any and all feedback is welcomed
  • Reminder that the release is scheduled for Thursday, May 17th

Updates from focus leads and component maintainers

  • The REST API team posted a summary from their last meeting covering decisions around `register_meta()` and documentation. Decisions are being made so if lead devs or component maintainers have input then please take the time to review and join the discussion. Many thanks to those who’ve joined the component lately, some important stuff has been getting closed out. #43998 is a priority and current needs a patch.
  • The Gutenberg team released v2.8, continue to iterate on regular releases, and thank everyone involved.
  • The PHP team posted recaps from their last two meetings covering Servehappy, PHP version requirements for plugins & themes, and the PHP upgrade page.

General announcements

  • @mikeschinkel: looking for input on #12955, its 8 years old but has recent discussions that could use feedback so those interested in contributing take the best approach

Next meeting

The next meeting will take place on May 16, 2018 at 20:00 UTC / May 16, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-6, #core, #dev-chat, #summary

X-post: Pair programming on the contributors day

X-comment from +make.wordpress.org/accessibility: Comment on Pair programming on the contributors day

Gutenberg and the REST API, early May

Since I last wrote two weeks ago, we’re making progress! Key achievements for Gutenberg and the REST API include:

  • Support for who=authors was added to GET wp/v2/users, making it possible to accurately query for authors. WordPress, for better or for worse, defines an author as user_level!=0. See WordPress/gutenberg#6361 for the context on why we can’t add this logic client-side (#42202 for WordPress 4.9.6).
  • Improved performance for the _fields= query parameter (e.g. GET wp/v2/pages?_fields=id,title) by ensuring WordPress core will only process the fields requested for the response. Notably, this helps us avoid running the_content when we don’t need to be (#43874 for WordPress 4.9.7).
  • Minor enhancements to reflect existing WordPress behaviors:

The “Merge Proposal: REST API” GitHub milestone represents the distance we still need to close. Slowly, steadily, we’re bridging the gap, but we could use your help. Here are some of the issues we’re still working through:

  • To ensure all necessary data is available to Gutenberg, we’ve settled upon permitting unbounded per_page=-1 REST API requests for authorized users. This landed for GET wp/v2/users (WordPress/gutenberg#6627), is in-progress for GET wp/v2/(pages|blocks) (WordPress/gutenberg#6657), and needs to be addressed for categories, tags, and custom taxonomies. We also need to patch core with this enhancement (#43998 for WordPress 4.9.7?)
  • Capabilities can’t be processed directly client-side (WordPress/gutenberg#6361), so we’ve introduced a new targetSchema concept to communicate which actions a user can perform. See it in action with wp:action-sticky (WordPress/gutenberg#6529) and wp:action-assign-author (WordPress/gutenberg#6630). There are a few other actions we will need to work out, and then we’ll need to patch core (no ticket yet).
  • @adamsilverstein is putting together an improved autosaves implementation (WordPress/gutenberg#6257) that I literally cannot wait to see complete. I’m sure he could use some help testing in the near future.
  • @flixos90 is implementing a WP_REST_Search_Controller endpoint (WordPress/gutenberg#6489) to power the link search UI.

Join us tomorrow, Thursday, May 10 at 17:00 UTC in #core-restapi office hours if you’d like to chat through any questions you have.

#gutenberg, #rest-api

Dev Chat Agenda: May 9th (4.9.6 week 6)

This is the agenda for the weekly dev meeting on May 9, 2018 at 20:00 UTC / May 9, 2018 at 20:00 UTC:

  • 4.9.6 planning
  • Updates from focus leads and component maintainers
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-9-6, #agenda, #core, #dev-chat

4.9.6 Schedule Changes

Last Thursday, 4.9.6 beta was released. In order to properly address all feedback received from beta testers, more time is needed.

After careful discussion, @desrosj, @allendav, @azaozz, and @sergeybiryukov have decided that to prevent any further set backs, both the 4.9.6 release candidate and 4.9.6 release by two days each.

The new schedule moving forward is as follows:

  • Release Candidate: Thursday, May 10th
  • Release: Thursday, May 17th

As previously detailed, 4.9.6 is not a typical minor release because of the inclusion of time sensitive features. In order to give site owners the personal data and information tools needed to be prepared for GDPR (General Data Protection Regulations) before the May 25th, 2018 effective date, these features cannot be removed to ship the minor version on time.

This decision was not made lightly. Deadlines are not arbitrary. However, it is important that the tools are ready and that translation contributors have enough time to localize the large number of new strings in the release.

Please continue to test the 4.9.6 beta package and provide feedback.

#4-9-6

PHP Meeting Recap – May 7th, 2018

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

At this meeting there was some continued conversation around plugins & theme php version requirements (see parent ticket here)

  • @sergey has made some progress on technical restrictions
  • #design feedback will be needed as a part of implementing how restrictions are communicated to the user.
  • Initial goal for this is block installation of plugins in environments that don’t match php requirements for the plugin.
  • @flixos90 is going to get in touch with the design team regarding feedback on the mockups.

Also on the agenda was continued conversation around design/layout work for the PHP upgrade page. We took a look at this mockup that was done by @jaymanpandya, however for the most part we felt that in order to progress on this, the feedback needs to come from the #design team itself and those involved in the design of the overall WordPress.org site. To that end, @flixos90 has created a ticket in meta for tracking this and this is a callout to anyone involved in #design (and particularly with regards to the overall design of WordPress.org and how this would fit in with that) to review the current mockup and add comments.

Next Meeting

Next meeting will take place on Monday May 14, 15:00 UTC in #core-php

Agenda:

  • Followup on php requirement restrictions for plugins/themes (hopefully with some design feedback).
  • Followup on PHP upgrade page design feedback (if there is any).

REST API Meeting Summary: May 3rd

This post summarizes the REST API component team meeting from May 3rd in #core-restapi (Slack archive).

Decisions around register_meta()

This meeting revolved around finding decisions on remaining questions regarding the approach for adding subtype support to register_meta(). Please read the announcement post for the meeting for background and context.

  • It was decided to go with the fourth approach outlined in the announcement post: Every registration of a meta key is accepted, regardless of whether the same meta key already exists on the same object type in another way. Meta keys registered for an object type and subtype will take precedence over meta keys only registered for an object type (i.e. less specific). This allows us to not having to deal with conflicts. Existing calls without using object types will continue to work – while they are now fallback, chances of a conflict are generally rather low in this way. Nonetheless, a major part of these improvements will involve precise documentation and education (more on that below).
  • Easy-to-understand wrapping functions will be introduced, such as register_post_meta(), unregister_post_meta(), and the same for terms, comments and users. In those functions, we can significantly help DUX: Instead of mentioning the very abstract term “object subtype”, we can here refer to it as the more common terms “post type”, “taxonomy”, etc. respectively.
  • New filters sanitize_{$object_type}_meta_{$meta_key}_for_{$object_subtype} and auth_{$object_type}_meta_{$meta_key}_for_{$object_subtype} will be introduced for metadata sanitization and metadata capability handling for specific subtypes. If one of these two filters is being used for the given variables, the existing sanitize_{$object_type}_meta_{$meta_key} and auth_{$object_type}_meta_{$meta_key} will not be executed – again, this is because metadata registration for an object type and subtype overrules metadata registration for only an object type.

An updated patch with the above changes is in place to test the current approach, available on the ticket #38323.

Documentation & Recommendations

The existing register_meta() function has not yet seen wide use in REST API-related plugins, so the transition to this new behavior should be smooth. However, should developers continue to omit object subtypes or fail to properly prefix their meta keys, over time the chance of conflicts between or within plugins will increase—therefore precise documentation and education are necessary to make all of this work in the long run.

To aid the transition to the new behavior, it will be recommended to switch existing calls to register_meta() over to include an object subtype. Additionally, we will no longer encourage direct calls to register_meta() when a wrapping function like register_post_meta() is available—this is in line with how it is currently preferable to call get_post_meta() over get_metadata( 'post' ), for example. We will also re-emphasize the importance of prefixing meta keys to ensure uniqueness.

Related Issues

Something that we will want to consider in the future is how to deal with meta keys of the same name that are registered for exactly the same object type and the same subtype. Currently, the second call would simply override the data registered by the first call. Alternatively, we could make the second call fail, keeping the first one the “winner”. However, this is a general problem in many areas in core (think about register_post_type() for example), so this may not be the appropriate point to discuss such a big topic.

May 10th Meeting Agenda

Next week’s meeting on Thursday, May 10th 17:00 UTC will continue to focus on discussing register_meta(), particularly review whether the current patch is a viable solution. We will also try to find an answer to the last, smaller question of the original announcement post, whether comment types should actually be considered subtypes in scope of metadata registration. If there is time left afterwards, we can also discuss the state of the current directly Gutenberg-related work in the REST API – otherwise this will happen the week after.

Please review the register_meta() ticket #38323 and the latest patch there, and chime in with your thoughts on the ticket or by attending the meeting!

#rest-api, #summary

PHP Meeting Recap – April 30th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

  • We first discussed whether we could have the current widget implementation backported to the upcoming minor release 4.9.6. @desrosj was positive about doing this, but left it open for a final review and someone with the willingness to actually commit it. One benefit would be to include this with the privacy policy changes, which has translators already be aware that a portion of new text strings need to be translated. Also, getting it in as soon as possible will finally allow us to get real feedback on its reception and effectiveness.
  • The “Upgrade PHP” information page needs a visual overhaul. It currently is a pure wall of text, and any change in that regard will be an improvement at this point. @schlessera will work on changing the page for a few quick wins to make it more digestible, and the discussion with the #design team needs to be relaunched.
  • As the first two components of the “Servehappy” initiative are now in a usable state, it is time to focus on the third component: enforcing the “Requires PHP” plugin header information.
  • There are several different mechanisms that need to be changed for enforcing the PHP version requirement, and we agreed to split the main ticket up into smaller subtasks so that blocking issues in one will not block progress in others.
    Here are tickets for the current subtasks:
    1. Disable “Install” (plugin) buttons – #43986
    2. Block updates to new plugin releases – #43987
    3. Allow filtering plugin searches by required PHP version – #43989
  • @afragen has already built a proof of concept that shows a basic implementation for blocking updates. This immediately points out a problem with the current API, which can only serve the plugin information for the latest release of a plugin. If we need to cycle to prior versions to do something like “find the latest version that still runs on PHP 5.2”, we’ll have to work on infrastructure changes as well.
  • Blocking updates does have security implications. We want to block updates to new versions that would bump the required PHP version past a version the server provides, but at the same time, we still want to provide the possibility for plugin authors to push security updates.

Post-meeting update

  • The Servehappy nag widget was not included in the beta of release 4.9.6. We should work on getting it backported early in the 4.9.7 release cycle.

Next week’s meeting

  • Next meeting will take place on Monday, April 7th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Discuss how best to relaunch the #design process and go over the individual tickets for enforcing the “Requires PHP” header.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core-php, #php, #summaries