Howdy again! We’ve actually been meeting the last couple of weeks but someone (aka: me) has been bad about posting meeting notes. If you’re interested in helping with internationalization efforts on WordPress.org, join us on Tuesdays at 12:00 UTC (note the time change for DST).
Here’s a few things that happened in the i18n world over the last couple of weeks:
- Translate: A bunch of things have happened!
@obenland swooped in with some updates to the project overview for plugins. Here’s an example. But I’ll save you a click: all four sub-projects are now represented on the page in a layout similar to the stats page. We hope to expand that page with other features in the future.
- Speaking of stats, @dd32 updated the Waiting column on the stats page to list waiting strings from all projects. Numbers grew substantially for many locales.
- Every time a plugin gets imported into translate.wordpress.org, the status is now displayed in the #meta-language-packs channel on Slack. Plugins that are already in translate.wordpress.org get re-imported every time there’s a commit in their SVN repository. In the future, initial plugin imports will also be shown in this channel.
- The above item was the last major step to enabling at-will plugin imports into translate.wordpress.org. @ocean90 has fixed a various bugs in the scripts and will be testing the feature (secretly) soon, to see if it will scale. Once he’s comfortable, it’ll roll out to a broader audience and eventually get announced to all plugin authors.
- One of the ways we can ensure it will scale is by setting up a job system and running all of our jobs through that. @dd32 has worked up some initial code for that, which we’re waiting on systems to deploy.
- But that’s not all! A filter UI is now available for larger groups of projects (like plugins and themes). You can see it for themes here.
- Additionally, Dion fixed the issue where themes with
\r\n in there strings were appearing incorrectly.
- Forums: More forum plugins are being ported! @nullbyte has signed up for a few plugins and the table has been updated.
Finally, at today’s chat we talked about #1388, #1044, and #1162, as well as related GlotPress tickets #100 and #494. Specifically, what is the best way to alert translators and translation editors of projects that strings are ready and available to translate?
There are a number of things we can do here, but for now the best course of action is adding a list of contributors/PTEs to the plugin overview (that’s #1388 for those following along). Adding this is a good first step towards future solutions.
While that’s being developed, it’s worth considering the best UX for notifying/contacting translators. The propose GlotPress method is notifications and a notification center, however our use case might be different than the norm – or perhaps we should work with the GlotPress developers on the ideal solution if our use case is normal.
Lots to think about and discuss with the polyglots team and propose to plugin/theme authors.
Earlier today a handful of us gathered to talk about life, the universe, and things that may or may not relate to the meta team and i18n. Here’s a bit of what we talked about:
Plugins: Last week imported our first set of plugins into translate.wordpress.org! Hurrah! Huzzah! 🎤⬇️ And because we were feeling good about it, we also sent out emails to the second batch of plugin authors (~200 plugins). That import will start today or tomorrow and we’ll send out emails for the next import soon.
Translate: The stats page got some love with the addition of the Waiting column (see #1202) and some improvements to the design (see #1238).
Theme Directory: @obenland started work on the Translations section by adding a link to translate any theme to the page. Check out the Twenty Sixteen theme page for an example.
WordCamp: Set things up so the WordCamp theme can be translated (see #1076), pending deployment by the WordCamp team.
Forums: There was a mention that the Italian forums are not working. @ocean90 will investigate. Additionally, we’ve had a couple of requests for new forums. We think it’s okay to add new ones for testing purposes. For example, an RTL forum would be appropriate.
For the next week, we’re planning to work on the following:
- Import and language pack status of plugins sent to a Slack channel.
- Sorting / Filter UI finished up (or whatever we call it).
- Streamline the process of adding per-project translation editors (see #1237 which requires #1240).
- Work on updated design for project pages in Translate.
- Possibly: More Theme Directory translation section additions.
- Possibly: Rosetta headers fixed up (see #1201).
- Possibly: Job system started.
See y’all next Tuesday at 11:00 UTC!
We met today, like normal, at 11:00 UTC and discussed the following things:
Translate: Warnings on translate.wordpress.org are now being sent to #polyglots-warnings for more transparency and to catch bad actors. (The channel name may change to #polyglots-notices to cover other usages.) Additionally, the “Waiting” tab now shows the full project name instead of just the sub-project name; e.g., “Plugins – Akismet – Development (trunk)” instead of “Development (trunk)” which was less descriptive.
Plugins: Last week, emails went out to the first batch of plugins. We are ready to begin the import into translate.wordpress.org.
Forums: @clorith has taken on a plugin! We love new contributors. 🙂
There was no update last week (on this blog) but we also improved the design of the stats page.
Over the next week, we intend to do the following:
- Plugin import, starting today.
- Import and language pack status of plugins sent to a Slack channel.
- Emails for next plugin import batch will go out.
- Sorting / Filter UI finished up (or whatever we call it).
- Possibly: Rosetta headers fixed up.
- Possibly: Jobs system started.
See y’all next week!
As a follow up for my earlier post on translation project sorting and compiling the comments/thoughts therein, I think we should start with the following things, in order by priority for implementing them.
Waiting Tab: It’s clear that translation editors need a tab just for waiting strings. This tab should be default for translation editors unless there are no waiting strings, in which case WordPress should be the default tab. If a user is only a translation editor for one project, it will show here. If a user is a translation editor for many projects, all will show here using the default priority sorting (see #2). If a user is not a translation editor for any project, they should not have a waiting tab.
Default Priority: With every tab, we need to establish a default priority, however the themes and plugins tabs will need it most. I propose the following default priority: Favorites, strings remaining (“0” goes to the bottom, “1” to the top), and by popularity. That means that your favorites will display at the top of the list, unless they have been fully translated. Further, if 10 plugins have two untranslated strings, all 10 will appear at the top of the plugins tab, in order by popularity, but below your favorites. Once a project is completely translated, it moves to the very bottom of the list, regardless of favorite status.
Filters: Within each tab, we need to ability to filter by the following things:
- Popularity within the directory
- Strings remaining (toggle between most/least; perhaps a “completed” option as well)
- Percentage complete (toggle between highest/lowest; perhaps a “completed” option)
- Waiting strings present in project
- Fuzzy/warning strings present in project
Future Filters: In the future, we should consider the following filters:
- Waiting age, especially on “Waiting” tab (aka, projects with strings that have been waiting for two weeks will appear before projects with strings that have been waiting two days)
- Release date for themes/plugins (aka, most recently updated first)
- Hide/show fully translated projects
How does that sound to everyone?
P.S. I’m out for next Tuesday’s weekly chat, but feel free to meet without me!
A few more things were discussed at this week’s meta i18n chat:
Translate Themes: Just a couple of things:
- All active themes were imported! But syncing hasn’t been enabled yet so a few newer themes (since the start of the import) are not yet imported. They will be soon, don’t worry. 🙂
- Language packs were enabled for themes! If a theme does not ship with translations and is fully translated into a language (in translate.wordpress.org), a language pack will be generated and automatically downloaded. Woohoo! Language pack generation is automatic. When a theme is fully translated (100%) in a language, a language pack will be generated. Some history from @ocean90:
- 2010 – First language packs for importers
- 2011 – Core ticket #18200 filed
- 2013 – Ticket #18200 closed as fixed (WordPress 3.7)
- 2014 – Language packs enabled for core (WordPress 4.0)
- 2015 – Language packs for third-party plugins and themes (WordPress 4.3+)
Translate Project Prioritization: I’m working up a detailed list of what we should do and when, based on the post from last week (and comments). Design-wise, we’re going to stick with what exists in the theme directory and modify as necessary.
Translate Import Queuing: There’s a lot of projects that will be added and syncing. We’re going to work up a queueing system in case things get overwhelmed. This is needed before we start importing plugins.
Rosetta Header: We need to “fix” the Rosetta header with the static, known sections, allowing Editors to add on at the end of it. Since we don’t have a showcase except on the homepage, my proposal is to set the following menu items: Home, Themes, Plugins, Forums (if they exist), Blog. Editors will be able to add additional menu items.
- (Note here that we should really add the Download button to the Rosetta headers as well.)
Over the next week, we’re going to continue to improve themes on translate.wordpress.org, including language pack work and synchronization. If there’s time, we’ll also start adding filters / prioritization to projects.
We’ve been collecting some ideas for sorting all of the projects that are being imported (themes and plugins). I want to collect some of the ideas here, along with my thoughts on them. If you have other ideas, we’d love to hear them!
- Prioritizing by popularity: Projects could be organized by how popular they are, that is, how many users and/or downloads they have. For translators, the projects that are used the most by users are often considered the most important.
- Prioritizing by fewest strings remaining: If a project is almost complete – e.g., just a few strings away – it can be considered higher priority. By enabling this option, we’d give translators a way to complete more projects faster. Personally, I think this is better than doing by percentage because 1 string remaining in a project of 10 is fewer than 10 strings remaining in a project of 1000, despite the latter being a lower percentage.
- Prioritize by permissions: If a translator is the translation editor for a specific project – or a few specific projects – we could show those projects first, since they have permission to approve translations for that project.
- “Hide” fully translated projects: If a project is fully translated and strings are fully approved, we could “hide” those projects or at least put them at the very bottom of the list. For themes and plugins, this will put them on the last page of results. Searching will still find them, of course.
- Starring or Favoriting: Everyone has one or two themes/plugins that they really love and want to see available in their language. Giving translators the ability to “favorite” a project and have it raise to the top would make it easier to keep track of new strings in their favorite projects. We could even create a new “tab” for “Favorites” that could be the default if a translator has favorites.
- Sort by waiting: Translation editors should be able to see which projects have waiting strings so they can approve them. Within this view, we should probably prioritize projects based on some of the ideas above.
- Improved search: Translators should be able to search by author name (theme or plugin) and see a list of their projects, for example.
- Consider “alerting” when changing a translation: It’s hard to explain this, but if I, as a translation editor, change the translation of “gallery” in one project, GlotPress should alert me to the fact that other projects have a translation of “gallery” that is the “old one” and possibly even offer to update all projects with the new translation.
The ideas above are just that: ideas. We may not implement any of them or all of them. But it’s important to list them and think through how we can improve the translation experience.
What other ideas do people have on sorting, prioritizing, and generally improving the translation experience of translate.wordpress.org?
As mentioned a few times, we’re going to be enabling the translation of active plugins and themes in the WordPress.org repositories on translate.wordpress.org. Today, we had a chat in #meta-i18n (logs) about how the non-technical side of this will work.
As a quick recap: We’re making good progress on the relevant pieces of Rosetta, GlotPress, and all the related scripts needed to import plugins and themes that are in the WordPress.org directories into translate.wordpress.org and make them available for translation. Every plugin and theme will then be able to take advantage of languages packs, meaning no more delay in language updates and smaller plugin downloads.
Here are a few of the points we discussed on how this process will work:
Eventually, all active themes and plugins in the WordPress.org directories will be imported into translate.wordpress.org and made available for translation. The “eventually” is important to note as we will be importing a few at a time to ensure GlotPress can scale accordingly. It’s also important to note that “active” is a theme or plugin that has been updated in the last year. Further, even plugins and themes that are not i18n-ready will be imported so that their descriptions can be translated.
- Additionally, any plugins or themes that do not live in the WordPress.org directories will not be allowed on translate.wordpress.org. For example, commercial plugins.
- During the initial import, we intend to import all strings – included translations – directly from the plugin’s svn repository on WordPress.org. We will not continuously import these strings, however. Ideally, after the initial import, a plugin would then delete the strings from the svn repository, making their download smaller and immediately taking advantage of the language packs generated by translate.wordpress.org.
- For a language pack to be updated, the string must be updated in translate.wordpress.org.
- The above point means that if a theme or plugin author uses a different site for translations, those translations must be brought over to translate.wordpress.org. If the theme or plugin has an active translation community, they can work with the polyglots team to bring translation editors over to the community. These translation editors can be limited to specific plugins, at the discretion of the locales translation editors. These translation editors can import strings for the plugin/theme, should they wish to continue using a different site for translations. (When we get closer to this, I’ll create a sample post that theme and plugin authors can use.)
That’s a lot to take in, so please let it digest. 🙂
One thing we also discussed was the possibility of enabling GlotPress installations to “talk to” each other, such that translate.wordpress.org could import strings from another GlotPress site (for example, translate.yoast.com), whether as a feature of GlotPress core or a plugin. Currently, this is an open question. We plan to discuss the technical questions of this possibility at next week’s #meta-i18n chat (Tuesday, July 14 2015 11:00 UTC). Note that we will not wait for this feature before continuing with our planned import.
A few other notes:
- We discussed the possibility of adding a banner to the specific plugin/theme’s page on translate.wordpress.org pointing the external site where translations are active, should a plugin/theme not use translate.wordpress.org as the canonical source for their translations. Currently, I believe the answer is “no banner” but it’s a conversation we should have and re-evaluate over time.
- Outside of that, it occurred to me after our chat that we will need to add translation editors to the relevant theme/plugin page. For example, if a translator editor only has permissions to approve translations for Hello Dolly, we should note that on the Hello Dolly page within translate.wordpress.org. Example: “Strings for [project name] are approved by the German translation editors [link], as well as username, username, and username.”
If you’re interested in any of this topic, we’d like to get some feedback on any/all of the above. Please leave your comments here, not in #meta-i18n, so others can see your feedback. We’re especially interested in feedback from plugin and theme authors who do not currently have translations and one’s who use an existing product for their translations.