Translations Abstraction Proposal for WordPress

plugins.svn.wordpress.org:

  • There is a new special folder in Plugin Repositories, at /assets/i18n/
  • A /assets/trunk.pot file should probably be maintained for support of repositories where trunk is their public release version.
  • Whenever a new tag is created, for example /tag/3.2-beta1 (a script automatically|the plugin author) generates the po/mo source files, and stores it as /assets/i18n/3.2-beta1.pot or the like.
  • I’m torn as to who generates this, and I have no desire for this to generate additional changesets on our already burdened plugins.svn.wordpress.org — perhaps they could live elsewhere, and wouldn’t necessarily need to be under version control.
  • A /assets/i18n/master.pot and the like file may be maintained which is a merger of all the strings in all the versions in all the tags.
    • This is to simplify things so that if a string is dropped from one version to the next, it is still included in a master index, potentially simplifying things from a storage perspective, so that if requesting translations for a plugin, a version number does not need to be specified, and GlotPress wouldn’t need to store fifty copies of the same string for the same plugin, if there are fifty different tagged versions.

plugins.glotpress.wordpress.org

  • I know very little about the inner workings of GlotPress currently, so I’ll leave this part of the proposal as a ‘black box’ that magically works.
  • Sharing identical strings between plugins would be amazing, if possible, but with the ability to break the link if one plugin author needs it to be translated differently.  But I suppose that can be done with _x() and notes for translators.
  • API requests for translations shouldn’t by default be given up-to-the-second results.  If there’s a cached version from the last 24 hours, or it hasn’t been invalidated with any new translations yet, just serve that version up.
  • Gzip it all in transit & storage.

core

  • This would be implemented as a plugin tentatively by using the 'override_load_textdomain' filter — which would then query the API and either store the translations in a transient/option, or in a folder within /wp-content/.
  • If not using a transient, set a wp_cron task to check for updates every X days, weeks, or on upgrades / installs / manually pushing the update translations button.
  • Store a version number for the most recently received translations, and pass that back with subsequent queries, so it only receives the strings that have been updated since the last pass (huge potential savings on bandwidth and server processing time).
  • On the (client|server) side, round the version number down to a given interval (thousand, ten thousand?) so that it can be cached more easily on the server side.  A couple duplicate translations could get delivered, but that’s a small price to pay for the savings in processing time.

Author: George Stephanis

Cooking, Code, Carpentry, Letterpress.