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.
Aside

Automattic!

Starting Monday, April 22nd, I’ll be working full time at Automattic!

When I first started working at Speck Products, I’d remarked to a friend that I thought I’d be there for good.  I loved the environment, I loved the people, and I said the only reason I’d ever leave is if Automattic ever wanted me and I could spend my days working full time on WordPress — more in a joking way, as I never really expected it to happen.

Eight plus months later, I find that to be exactly the situation I’m in.

I can’t find a single thing to gripe about regarding my tenure with Speck.  Everyone there was an utter joy to work with.  Challenges were plentiful to keep me engaged, but never overbearing.  I was kept occupied, but never overburdened.  Everyone was friendly and provided a great atmosphere.

However, now I’ll get to do something that I count myself as incredibly fortunate for.  I get to spend my days  doing the sort of work that I’ve volunteered my time doing for the past year and a half.  The environment that has been my passion, is now my job.  And I couldn’t be happier.

I’ll be spending my days on the Jetpack team for Automattic, increasing the tools available to WordPress.org users through WordPress.com by way of the Jetpack plugin.  I’m very excited by the road map we’ve got going forward, and I can’t wait for some of you to see the features that we’ve got in store.

The best is yet to come.

Make your nav stick to the top of the screen when you scroll past it!

A pretty simple JS include to use when you don’t already have jQuery or the like included on a page.  Just adds a data-nav=”fixed” attribute to your body element that you can style off of via body[data-nav="fixed"] .whatever {} — this also has the benefit of not hardcoding any styles — you’re free to do it all via your CSS files.

Just remember to swap out ‘nav’ for whatever ID or selector you’ve got on your actual nav.

Potential optimizations would be not using document.getElementById over and over, and just leaving the element cached in a global.  I would advise against caching nav’s offsetTop, though — as it’s possible that things may change in the dom, and that could change!

window.onscroll = function() {
    var d = document,
        nav = d.getElementById( 'nav' ),
        att = ( window.pageYOffset > d.getElementById( 'nav' ).offsetTop ) ? 'fixed' : 'normal';
    d.body.setAttribute( 'data-nav', att );
}