As mentioned a few times, we’re going to be enabling the translation of active plugins and themes in the 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/ 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 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 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 Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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.
#i18n, #meeting, #plugins, #themes, #translations