Proposal for Plugins Localization System

Since Nikolay confirmed that nothing has been done, and didn’t say anything about plans (which I assume means there aren’t one), and since there is continuing need for this from both developers and translators, I want to move process from a death point and speed up making of this system.

We all waited enough, we were patient, but everything has its limits. We don’t want this long-term but short-term, and definitely we don’t want to have a bunch of GlotPressGlotPress GlotPress is the translation management software that powers More information is available at installations.

Much, much more time, energy, resources (which all also mean money) are spent now on decentralised, dysfunctional system, than what would be spent on creation of a useful system which would help developers, translators, and users.

I don’t say that what I suggest is good and that should be done just like that, or that isn’t planed same or very similar, but it is a starting point, and since we already don’t have anything, a way for both translators and developers to express their opinions and to push 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. maintainers.

In this proposal, I paid attention to personal experience from both translating and maintaining of a pluginPlugin 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 Plugin Directory or can be cost-based plugin from a third-party, issues mentioned in the past, existing tools, how hard is to make this, and being future proof.


  • GlotPress installation at is repositoryWordPress Localization Repository The WordPress Localization Repository at is a Subversion repository where official WordPress translations are maintained. See Working with the Translation Repository for details. of plugins translations.
    • New projects are made by one of following options:
    • automatically for every plugin
    • by “command” in readme.txt (preferred)
    • by plugin’s author at admin tab
  • For each plugin, every language from WordPress translation project is added with current validators, and with plugins authors as admins. They’ll later have option to add more validators.
  • Cron (or whatever its name at plugins repository is) checks if there are changesets since last check, and if there are, generates new POT filePOT file POT files are the template files for PO files. They will have all the translation strings left empty. A POT file is essentially an empty PO file without the translations, with just the original strings. and updates stringsString A string is a translatable part of the software. A translation consists of a multitude of localized strings. at GlotPress.
  • Each plugin has two branches at GlotPress: Development and Stable. Plugins can have many versions so it’s impractical to have branch for all of them. Also there is no need for translations of older versions since their usage (in term of downloading) is low.
  • Since some plugin authors use only trunk for both development and stable versions, there could be only Development branch if there are no tags, or if stable tag is one from trunk. If plugin starts using tags for stable version, Stable branch is created with strings from stable tag. If plugin switches to using trunk for stable version, both Development and Stable tags are updated with strings from trunk while language files are generated from Development branch (there should be option to inform developer about this bad practise).
  • Cron checks if there is a change at GlotPress since last check, and if there is, generates a new language files.
  • For each language, separate archive file of plugin is created, with language code in name and with translations only in that language (as for WordPress, example for file name is For automatic install/upgrade via WordPress, depending on language code of installation, will provide link to appropriate plugin version. On site, there will be label that says that default version is in English (US), with link to separate page that lists all other languages (as for other versions now).


  • This proposal suggests usage of existing tools: there is the way to mass create projects, languages and add validators, there is plugins archives generator that is run on 15 minutes, there is a potbot, there is the way to export translations from GlotPress. The only thing that is missing is ability to have per-project admins in GlotPress, and I am not sure if check for changes at GlotPress can be done right now but coding of second shouldn’t be very hard, while for first it can be temporary created without per-project admins who can be bulk added later. So it shouldn’t involve a lot of coding of a completely new code, there is already a basis that should be adapted.
  • Folder languages is de facto standardized as a location for translations so POT, PO and MO filesMO files MO, or Machine Object is a binary data file that contains object data referenced by a program. It is typically used to translate program code, and may be loaded or imported into the GNU gettext program. This is the format used in a WordPress install. These files are normally located inside .../wp-content/languages/ should be placed over there.
  • This summer, on mailing there was discussion initialized by problem mentioned in first paragraph of this post, and issue of large archives size (because all translations are in it) came up, so solution with per-language archives seemed most logical.