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 GlotPress 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 wordpress.org maintainers.

In this proposal, I paid attention to personal experience from both translating and maintaining of a plugin, issues mentioned in the past, existing tools, how hard is to make this, and being future proof.

Proposal

  • GlotPress installation at translate.wordpress.org is repository 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 file and updates 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 plugin-version-lang_code.zip). For automatic install/upgrade via WordPress, depending on language code of installation, api.wordpress.org will provide link to appropriate plugin version. On wordpress.org 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).

Notes

  • 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 files 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.