After the blog post about JavaScript internationalization, we held a first meeting last Tuesday to discuss how we can improve client-side translation The process (or result) of changing text, words, and display formatting to support another language. Also see localization, internationalization. in JavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. https://www.javascript.com/.. This is a summary of the JS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. I18N Internationalization, or the act of writing and preparing code to be fully translatable into other languages. Also see localization. Often written with a lowercase i so it is not confused with a lowercase L or the numeral 1. Often an acquired skill. chat from May 8th, 2018. (Slack log)
Topics
First, we talked about the introductory blog (versus network, site) 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 The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://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 A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party and theme developers.
- Larger plugins like Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/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