Plugins, Themes, and

As mentioned a few times, we’re going to be enabling the translation of active plugins and themes in the repositories on 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 directories into 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 directories will be imported into 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 directories will not be allowed on For example, commercial plugins.
  • During the initial import, we intend to import all strings – included translations – directly from the plugin’s svn repository on 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
  • For a language pack to be updated, the string must be updated in
  • The above point means that if a theme or plugin author uses a different site for translations, those translations must be brought over to 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 could import strings from another GlotPress site (for example,, 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 pointing the external site where translations are active, should a plugin/theme not use 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 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.

#i18n, #meeting, #plugins, #themes, #translations

As we’ve been doing weekly we had another…

As we’ve been doing weekly, we had another meta trac triage yesterday. @atimmer, @coffee2code, @iandunn, @nacin, @Otto42, and @samuelsidler attended.

We’d love some feedback on #30. That is, anyone interested in creating better theme preview data, it’d be great to have it submitted to the ticket. There’s a current proposal that could use some feedback as well.

@jenmylo: For #482, will the training team be using their P2 or using the community P2? They’ve been using the community one recently. If they’ll continue to use the community P2, we can wontfix that ticket.

Next week (Friday at 17:00 UTC), we’ll be looking at the Plugins Directory component (I won’t be present).

#meeting, #triage

We did a meta trac triage on Friday…

We did a meta trac triage on Friday.

  • @Clorith, @coffee2code, @georgestephanis, @iandunn, @otto42, @samuelsidler attended
  • We’ll be doing another meta trac triage exactly a week later on May 16, 2014 17:00 UTC.
  • Our focus this time (and next) was on the General component in trac and closing out some of the issues. We made it through about half of the tickets in that component (20) and a handful were fixed.
  • @otto42 wants to ask anyone and everyone for help with responsive fixes for (#461)
  • A number of tickets need follow up. Some have been assigned so we know who’s on point. I’m taking a number of others.

Those interested, we’ll see you next week!

#meeting, #triage

We’re going to do a meta trac triage…

We’re going to do a meta trac triage this coming Friday at 17:00 UTC (10am PDT, 1pm EDT) in #WordPress-meta. We’ll be steering clear of devhub tickets (the devhub chat is a good time to look through those) and focusing on older tickets. If you’re interested in working with the meta team, join us!

#meeting, #triage