P.S. Pressgram Violated Kickstarter’s Own Rules

September 7, 2013

So, last night I was able to finally realize what it was about Pressgram that bothered me so much.

Just to be clear, I have absolutely no objections to companies getting bought. It’s part of the natural business cycle. I’m a bit iffy on companies who are started for the sole purpose of being bought out for piles of money (and have been approached by several trying to hire me on and offer me a stake), but that’s tangential to the point.

Normally, when someone starts a company, they get funding in exchange for a stake in the company, and then have to pay out to their stakeholders if they get purchased. Totally fair — the stakeholders make an investment, and get a payout.

With Kickstarter, folks pay in, to typically get something out of it. A product, some stickers, a big thank you, whatever it happens to be. It front-loads a lot of the funding, and lets the creators build something awesome, which is then dispensed to the backers, and the creators can then go on to continue with it on their own, or build something else.  The expected pay out is known going in.

My concern (that I really hope I’m wrong on) was that Pressgram was trying to juice the system on both ends. Get the capital influx from Kickstarter by portraying itself as a product that folks would be able to use when it launched so that they didn’t need to put their own skin in the game to get launched, force people to sign up and build a user base, and then get bought out for ‘piles of cash‘ as an exit strategy. Basically trying to reap where one had not sown and profit with zero risk?

When I mentioned my concern that Pressgram had run its Kickstarter as though it were offering a standalone app (which, based on folks reactions to my posts, it certainly came across that way), John Saddington replied:

Respectfully, you didn’t read far enough! The social network was a part of the original design, from Day #1 of the campaign!

I couldn’t put my finger on just why that bothered me so much, or why he had made the references to a social network so vague and hard to catch.

Then I realized it, about a half hour ago. From the Kickstarter Guidelines as to what may and what may not be Kickstarted:

Kickstarter cannot be used to fund e-commerce, business, and social networking websites or apps.

Of course the original Kickstarter campaign couldn’t explicitly say that it was funding the creation of a social network. Those are explicitly forbidden!

So there’s two situations that remain: Either John Saddington kickstarted an app, or he kickstarted a social network. If it was an app, he should deliver on the Kickstarter and let the app work solo — without the requirement of being connected to the Pressgram social network (even if it results in a couple fewer users if he tries to get bought out). If it was a social network, then it was in direct violation to Kickstarter’s own rules.

Or, y’know, just say that he decided not to deliver the product that he kickstarted, and built this other product (that happens to have the same name) instead — but that’s a really dangerous precedent, and would kinda kill any future trust.

So, which is it?

Pressgram Terms of Service

September 6, 2013

NOTE: This is the second of two posts looking at problems I see with Pressgram. The first, looking at security concerns, can be read here.

First, a bit of history.  No, it is too long, let me sum up:

Pressgram was first spawned as a Kickstarter as a reaction to the Instagram Licensing debacle where there was an addition to their Terms of Service which implied that Instagram had the right to resell your photographs without payment or notification.

The Pressgram Kickstarter made some awesome claims:

You see, I want to build an independent publishing platform that isn’t beholden to strange and changing Privacy Policies, Terms of Service, or Licensing agreements […]

I suppose another way you could say it is… it’s your filtered photos published directly to your WordPress-powered blog, when you want, where you want, how you want.

You see, you now get more creative control over your content than ever before. You won’t have to “license” your photos from the app or the company – they are yours forever and you’ll never see them anywhere else except your own profile and blog.

This is a boon for the artist, the creative, the independent content creator who doesn’t need to worry about digital agreements or where they may end up seeing their own handiwork.

It’s yours, for goodness sake. No worries here.

You see, we believe that true creative control is not just about act and process of creating but also publication, especially in today’s digital economy.

Gee, that’s pretty slick.  It’s all about letting me keep the rights to my own content!

Well, no.

If you read their Terms of Service, you’ll see this section, reproduced in full:

User Content Submitted Or Made Available For Inclusion On The Service

TL;DR: Your photos are YOURS, now and forever! We do not hold ANY rights or intellectual property related to your content except for those that allow us to provide the Pressgram app and service to you. Also, your photos will preserve whatever copyright they had before uploading to this site and we will seek to protect that copyright and will not sell your photos without your permission!

By posting any User Content on the Service, you expressly grant, and you represent and warrant that you have all rights necessary to grant, to Pressgram a royalty-free, sublicensable, transferable, non-exclusive, worldwide license to use, reproduce, modify, publish, list information regarding, edit, translate, distribute, syndicate, publicly perform, publicly display, and make derivative works of all such User Content and your name, voice, and/or likeness as contained in your User Content, in whole or in part, and in any form, media or technology, whether now known or hereafter developed, for use in connection with the Service and Pressgram’s (and its successors’ and affiliates’) business, including without limitation for promoting and redistributing part or all of the Service (and derivative works thereof) in any media formats and through any media channels. You also hereby grant each User of the Service a non-exclusive license to access your User Content through the Service, and to use, reproduce, distribute, display and perform such User Content as permitted through the functionality of the Service and under this Agreement.

Well, if you read it fully, the TL;DR: section at the top certainly seems to be misleading.  An easy summary that makes you want to gloss over the fine print that — remember — by the Kickstarter, Pressgram wasn’t meant to be “beholden to strange and changing Privacy Policies, Terms of Service, or Licensing agreements.”

By the summary, Pressgram doesn’t hold any rights except those needed to provide the service and app.  Which would be awesome.  But it’s not what the terms actually say.

You are granting Pressgram the royalty-free rights to do the following:

  • Reproduce your images
  • Publish your images
  • Modify your images
  • Edit your images
  • Syndicate your images (which means to publish or broadcast in newspapers or TV)
  • Publicly display your images
  • Make derivative works of your images
  • Use your name, voice, and likeness as well, in any of the aforementioned ways

… and they can sublicense and sell/transfer those rights any way they like!

Then, it goes on so that you’re giving every other user of the service a license to use, reproduce, distribute, display your images as well.

Now, this is all very odd considering this is giving Pressgram the very same rights that it was created to protest Instagram trying to claim!

In fact, let’s take a look at the Instagram Terms and Conditions as they were when the whole ruckus came about (not their current terms, the more objectionable ones that they eventually backed down from).  You can view them here.

Instagram does NOT claim ANY ownership rights in the text, files, images, photos, video, sounds, musical works, works of authorship, applications, or any other materials (collectively, “Content”) that you post on or through the Instagram Services. By displaying or publishing (“posting”) any Content on or through the Instagram Services, you hereby grant to Instagram a non-exclusive, fully paid and royalty-free, worldwide, limited license to use, modify, delete from, add to, publicly perform, publicly display, reproduce and translate such Content, including without limitation distributing part or all of the Site in any media formats through any media channels, except Content not shared publicly (“private”) will not be distributed outside the Instagram Services.

As a reminder, these are the original Instagram Terms of Service, the ones that got the internet in a huge fuss, and Pressgram rode the wave of frustration with to over $50,000 of funding.

Now, that reads nearly identically to the Terms of Service that Pressgram has listed above!  You’re giving them a non-exclusive, perpetual, royalty-free license to do … well … pretty much anything they want with it.

Pressgram had some pretty noble ideals.  However, by claiming transferable and sublicensable rights to publish and create derivative works of your images, it’s showing that all the attractive talk about how “you get to control any and all commercialization of your content and work, how it always should have been” really is just gilding the lily, as it’s utterly negated in the small print in the terms of service, which Pressgram started out by saying  that it was entirely opposed to.

If Pressgram were built as just an app, instead of a Social Network (and we totally need another social network clogging up the internet), it wouldn’t have these Terms and Conditions, as you would be using it to modify your own images.  No service to store your images and share them on your behalf.  No server to distribute your images for you.  You’d send your own images directly to your own site, no messy, needless intermediate service to get in the way.  Which is much simpler.

But instead, what was built as Pressgram is functionally indistinguishable from Instagram, except that it publishes to your WordPress blog, and stores your WordPress credentials on their server.  It still claims the same rights to your images that Instagram did when it was initially conceived, and far more rights than Instagram claims in their current Terms of Service.

However, there is hope.  It sounds like John Saddington is taking these concerns to heart and looking into them over this weekend.  Here’s hoping the fine print clarifies itself to match Pressgram’s initial noble ideals, or the Pressgram app opens up and makes the service, and therefore its Terms of Service, opt-out.

UPDATE: Pressgram has updated their Terms of Service, making clear that it’s taking fewer rights to your content, and that those rights are only to be used for displaying your content, and it is no longer claiming the rights to sublicense or transfer those rights.  Hurrah!  It’s now in line with Instagram’s current Terms of Service.

Unfortunately, now it added this little blurb:

You agree not to reproduce, duplicate, copy, sell, resell or exploit any portion of the Content, use of the Content, or access to the Content without the express written permission by Pressgram.

I’m assuming that’s a typo, meant to read “without the express written permission of the original author and owner” — will update when that gets clarified.

Pressgram Security Concerns

September 6, 2013

NOTE: This is the first of two posts looking at problems I see with Pressgram. The second, addressing the Terms of Service can be read here.

Hi, folks. Gather round, and let’s have a little chat about password security and transparency.

So Pressgram just released, after a rather successful Kickstarter campaign, and lots of excitement by the community. Hurrah, congratulations, folks! Getting a public release actually shipped is the toughest part of any project, and you’ve got that out. Well done!

I installed the app last night, kicked the tires, and examined how it operates a bit, and I’ve got some concerns that I’d like to voice.

First, though, a bit of background. On the official WordPress Mobile Apps, there’s only so much security that can be reasonably achieved via the XML-RPC API that they (and pretty much all apps) use. With XML-RPC, there are no authentication tokens, you need to send your password in plaintext. Which is normally totally fine, as the password is just stored by your local phone (the security of which you are responsible for yourself), and then stored in a double-hashed and salted form on the server.

It seems that, unlike the WordPress Mobile Apps, the password that you enter in Pressgram isn’t kept private on your own device. Without noting it on a Privacy Policy or in any way notifying you that Pressgram is doing it, your password is stored in plaintext on their server. Which — to be fair — is necessary, if they’re going to be pushing data from the Pressgram Server to your WordPress site, and not going to require having a specialized plugin (like Jetpack) installed on your WordPress site to do it. And I don’t think that Jetpack is necessarily a worthwhile dependency to have for an app like this.

My first concern is that I don’t really like my passwords being stored in plaintext on a third-party server that could be hacked (or for that matter, required to be turned over by an order from a FISA court). Some other applications, such as IFTTT do the same thing, but at least with them, it’s transparent that it’s going to be their server holding your credentials and accessing your WordPress site.

With Pressgram, without further investigation, one would believe that it’s the app directly uploading the files to your WordPress site. After all, that’s what the Kickstarter initially pledged:

I suppose another way you could say it is… it’s your filtered photos published directly to your WordPress-powered blog, when you want, where you want, how you want.

But that’s not the case! For the curious, here’s what I saw when running a test against a honeypot standalone site where I was trapping all the requests sent to it:

Firstly, the App sends two requests to /xmlrpc.php

XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:51 +0000] "POST /xmlrpc.php HTTP/1.1" 200 904 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:51 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>system.listMethods</methodName><params></params></methodCall>
XXX.XX.XXX.XXX - - [06/Sep/2013:02:51:52 +0000] "POST /xmlrpc.php HTTP/1.1" 200 512 "-" "John.Saddington.Pressgram/1.0 (unknown, iPhone OS 6.1.4, iPhone, Scale/2.000000)"
[Fri Sep 06 02:51:52 2013] [error] [client 174.59.108.165] <?xml version="1.0"?><methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value><string>admin</string></value></param><param><value><string>password</string></value></param></params></methodCall>

These two requests firstly make sure that the site is there and is a WordPress install, and secondly makes sure that the credentials work — and if it’s a multisite install, returns the available blogs.

So far, so good. The User Agent strings are clear as to what they are and what they’re accomplishing.

Then, ten requests come in:

YY.YYY.YYY.YYY - - [06/Sep/2013:02:53:27 +0000] "POST /xmlrpc.php HTTP/1.1" 200 1845 "-" "-"
[Fri Sep 06 02:53:27 2013] [error] [client YY.YYY.YYY.YYY] <?xml version="1.0" encoding="iso-8859-1"?>
<methodCall>
<methodName>wp.getTerms</methodName>
<params>
<param>
<value>
<int>1</int>
</value>
</param>
<param>
<value>
<string>admin</string>
</value>
</param>
<param>
<value>
<string>password</string>
</value>
</param>
<param>
<value>
<string>category</string>
</value>
</param>
<param>
<value>
<array>
<data/>
</array>
</value>
</param>
</params>
</methodCall>

and nine others very much like it. If anyone is curious to see them, tweet me, and I’ll post them for folks to review. Checking existing taxonomies, creating new terms, uploading the photo, and creating the post.

XXX.XX.XXX.XXX is the IP address of my phone. YY.YYY.YYY.YYY is the IP Address of the Amazon Cloud Server that Pressgram works off of. I’ve anonymized these just for the sake of privacy. They’re easy enough to find, but it’s not my business to release them. I’ve also removed the base64 encoded image data.

I’ve also captured the request that the Pressgram App uses to send your password up to the Pressgram server — it looks something like this:

URL: https://api.pressgr.am/index.php/Api/postPhotoData
Data:
{
	"social": {},
	"post_content": "Pic",
	"sessionId": "00000000000000000000000000000000",
	"blog": [{
		"title": "Pic",
		"password": "password",
		"login": "admin",
		"url": "honeypot.example.com"
	}],
	"identifier_photo": "0000000000.0000000000"
}

So at least it’s being sent to the Pressgram server over HTTPS.

You’ll notice that the requests coming from the Pressgram Server have no User Agent to identify what they’re there for. They’re all signed with username and password — meaning that the Pressgram servers now have my username and password in plaintext, with not even a notification to me in their Privacy Policy or Terms of Service that this is being transferred up to their servers.

So what does this all mean?

Well, it means that Pressgram is storing your credentials in plaintext (or potentially encrypted alongside a decryption key) on your behalf, without notifying you or doing anything publicly to indicate that this is the case. No matter how high entropy your passwords may be, if you hand it to someone and they get hacked, it doesn’t matter. You are vulnerable — doubly so if you use that password for other accounts as well.

To some folks, this may be a worthwhile tradeoff. But as I look at it, I don’t see it as a necessary tradeoff. Your credentials could just as easily be kept private between the app on your phone, and your WordPress site. Just have your phone upload the photo directly to your WordPress install. It wouldn’t be difficult to do, it’s already making XMLRPC requests to the server. And it fulfills the initial Kickstarter promise of “your filtered photos published directly to your WordPress-powered blog”. It also would provide the added security that if Pressgram is eventually shut down or sold off, the app would still function, as it’s not needlessly dependent on the Pressgram Servers.

To protect yourself, you may want to consider making a seperate account for your WordPress site with the Author role, and using those credentials with Pressgram, and make sure you’re using a distinct password — as well as with any service that you provide a password to.

Conclusion

So in the end, what am I calling for?

Ideally, I’d like to see Pressgram give users the option of simply taking photos, and uploading them directly from the app to their WordPress blog. No servers in the middle with potential vulnerabilities for your data. In short — make the account creation and login optional. Give folks a choice! That sounds a lot more like what the Kickstarter was proposing. If you’d like to build a new social network on top of it (if I had a dime every time a potential client tried building that), make it optional!

Do I see that happening? Well, I hope so, but I’ve found that companies don’t normally like to make themselves less integral to a process. So at the very least, notify your users that their credentials are going to be stored on your servers. To take them as Pressgram has without any such public warning I see as morally questionable, and totally contrary to the values of the WordPress community, which embraces transparency, and not forcing unnecessary service dependencies between you and your site.

UPDATE: Pressgram has updated their Terms of Service to indicate that your content may travel through their network to get to your blog.  Unfortunately, it says nothing in the TOS or its Privacy Policy about your username and password being stored on or passing through its servers.

Serial TV Dramas that are Worth the Watch

August 31, 2013

Babylon 5

Summary:

It is the dawn of the third age of mankind, the middle of the twenty-third century. Man is far from alone in the universe.

A hundred years ago, humanity made contact with its first alien civilization — or more to the point, they made contact with us. Before the arrival of the Centauri, we were confined to our own solar system, forced to use slow sleeper ships to explore the universe. The Centauri gave us the stars, offered us the use of their “jumpgates” — portals into hyperspace — and later, taught us to make our own. In exchange for this and other technologies, they asked only for trinkets, novelties to sell back home.

In the eighty years that followed, humanity flexed its muscles, expanding outward at a rapid pace. When a group of less powerful races was attacked by an invading army, Earth came to their aid, cementing its role as a major galactic power, if a young, brash one.

The wave of euphoria came crashing down when humanity made contact with a mysterious race called the Minbari. The Earth-Minbari War began with a misunderstanding, a human captain and a Minbari commander too quick on the trigger. Thanks to bad luck or something darker, our first meeting with the Minbari resulted in the death of their supreme religious and political leader. To the Minbari, what followed was a holy war, vengeance for the murder of their spiritual leader. Earth was no match for the technologically superior Minbari, and they easily beat us back to our home planet.

Then, without explanation, as their ships closed in on Earth and wiped out our last desperate defenses, the Minbari halted their advance and surrendered. Only an elite few knew why.

The Babylon Project was conceived in the aftermath of the war. Modeled after the United Nations, it would be a meeting place, neutral ground where the powers could meet and work out their differences peacefully.

The first three Babylon stations were sabotaged in mid-construction. The fourth was completed, but just as it was about to go online, it vanished without a trace. The Earth government would have stopped there, but some of the alien governments, seeing the value of a meeting ground, offered financial assistance for the construction of a fifth station. Naturally, there were strings attached.

Babylon 5 is the story of the last of the Babylon stations, the last hope for a galaxy without war. It begins in the year 2257 with the opening of the Babylon 5 station.


Unlike most television series, Babylon 5 is a single story, completely planned out from day one with a beginning, middle, and end. Each episode is enjoyable on its own, but is also a piece of a larger whole, a chapter in a five-year-long novel for television.

(summary swiped from The Lurker’s Guide to Babylon 5)

Viewable on:

24

Summary:

Jack Bauer is a officer on Los Angeles CTU (Counter-Terrorist Unit). Each season takes place over a 24-hour period, and all 24 episodes proceed in real time. It does require a bit of suspension of disbelief, as phone batteries never die, and people neither eat, sleep, or use the restroom facilities, but it is a very engaging show.  Ideal for binging.

Viewable on:

Others that I have yet to flesh out:

  • House of Cards (US)
  • Deep Space Nine
  • Hustle (UK)
  • Spooks/MI-5 (UK)

Events Custom Post Type Proposal for Multisite

August 24, 2013

This is intended for the Make.WordPress.org series of blogs.  There are a number of needs, from weekly chat schedules for some Make blogs, to WordCamps for others.  Each site needs to be able to display their own events, and the main Make site would need to be able to display an aggregate of all (or some) of the sub-sites.

I see the implementation of the output (data structures will be addressed separately) being done via a shortcode, as follows:

[super-spiffy-event-calendar]

which would do stuff roughly like:

$events = Super_Spiffy_Event_Calendar::get_events();
Super_Spiffy_Event_Calendar::render_plugins( $events );

Not really tricky.  That will display any events from the multisite blog that you happen to be on.  However, for the aggregate, I see something more akin to this:

[super-spiffy-event-calendar blog_ids="2,3,4,5,6,13,14,19,22"]

which would be more akin to:

$original_blog_id = get_current_blog_id();
$events = array();
foreach ( $blog_ids as $blog_id ) {
	switch_to_blog( $blog_id );
	$events = array_merge( $events, Super_Spiffy_Event_Calendar::get_events() );
}
switch_to_blog( $original_blog_id );
Super_Spiffy_Event_Calendar::render_plugins( $events );

A couple things we’d need to add in that aren’t noted here:

  • Caching. Shove it in a transient, so we’re not doing an expensive operation with blog switching on every page load.
  • Sorting. After building the aggregate, it’s probably worth sorting the events chronologically.
  • Display. I’d like to use http://arshaw.com/fullcalendar/ or something similar to handle the output.

Get Remote Part — a handy theme function

August 21, 2013

Handy little code snippet if your theme or plugin ever needs to regularly check a remote url’s contents, but you want to cache it for a bit:

function get_remote_part( $url, $minutes_to_save = 60 ) {
	$transient_name = 'get_remote_part_' . substr( md5( $url ), 16 );
	if ( false === ( $value = get_transient( $transient_name ) ) ) {
		$value = wp_remote_retrieve_body( wp_remote_get( $url ) );
		if( $value ) {
			set_transient( $transient_name, $value, ( MINUTE_IN_SECONDS * $minutes_to_save ) );
		}
	}
	return $value;
}

My Two Cents on Two Factor

August 14, 2013

Two-factor authentication should (imho) be in core, but core can’t always provide the best ways to accomplish it, for example, text messaging which requires external APIs.

What I see the best fit being, is this:

There is a framework for Two-Factor Authentication in core, that provides two free no-api-required methods for users to select to validate:

  • Email (with a warning that it’s not as secure)
  • Time-based One-time Password Algorithm (TOTP)
    • This is what Google Authenticator / Authy use.
    • IETF RFC6238

Beyond this, Core would offer a filter to permit plugins to register other authentication methods, for example, Duo Security’s push-based request system, or Jetpack could provide a gateway for text-messages, just as they are sent from WordPress.com.

We would also need to allow a define( 'DISABLE_TWO_FACTOR_AUTH', true ); line in wp-config.php that would switch it off, in case a site owner lost their phone and needed to disable it temporarily.  I could also see use for a customized define to only disable it for a given user.  Ideally this would add a warning to the adminbar for all users that have manage_options() to notify them that it has been disabled.

Other dependencies that would need to be in core:

  • Application Passwords
    • For systems where the user cannot be prompted for a two-factor auth code (XMLRPC, etc), disallow their normal password for authentication, and force them to use a generated application password that is stored in usermeta.
    • For systems where the user can be prompted for a two-factor auth code (wp-login.php) don’t permit the use of application passwords.
  • Backup Auth Codes
    • Saved in usermeta, not terribly much interesting here.

ComicPress and Jetpack Photon

August 10, 2013

Howdy, all! Just a bit of a reminder if you’re a webcomic creator, and you’re running your webcomics on WordPress, you can get a pretty big performance improvement (and savings on bandwidth costs) if you activate the Photon module in Jetpack.

http://jetpack.me/support/photon/

Photon is a free Image Content Delivery Network hosted by WordPress.com. For most content images (depending on how your theme is serving them up), it will just swap out a CDN url of the image automagically, nothing to configure.

If you’re using ComicPress, though, it’s got some funky ways of outputting images just due to legacy code.  It’s pretty easy to fix, though:

Just upload this as a new file entitled comicpress-photon.php to your /wp-content/mu-plugins/ folder — or add it into your theme (or preferably child theme)’s functions.php file (but without the opening <?php)

It’s a huge savings on your hosting account because when serving images, your shared host has to keep talking to the client the entire time that the image is downloading, which can occasionally take longer than creating the page that the image is embedded in! So if your webserver has less load, it behaves better, your hosting company is probably happier with you, it’s not getting choked with serving up images when it could serve up HTML or the like, and you’ll instantly become 200% more attractive! (Okay, I lied on the last one)

Protected: Pay no heed to the man behind the curtain!

July 10, 2013

This content is password protected. To view it please enter your password below:

Translations Abstraction Proposal for WordPress

June 25, 2013

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.

Follow

Get every new post delivered to your Inbox.

Join 2,920 other followers

%d bloggers like this: