[buddypress-trac] [BuddyPress] #4857: Automatic download of translations from translate.wordpress.org

[buddypress-trac]

#4857: Automatic download of translations from translate.wordpress.org
-----------------------+-----------------------
 Reporter:  DJPaul     |       Owner:  DJPaul
     Type:  task       |      Status:  reopened
 Priority:  normal     |   Milestone:  1.8
Component:  i18n       |     Version:
 Severity:  normal     |  Resolution:
 Keywords:  has-patch  |
-----------------------+-----------------------

Comment (by nacin):

 Okay, so, this looks awesome. Fantastic job, Paul. Unfortunately, I agree
 with the revert ''for now''. JJJ summed that up really well. Let me go
 into further detail. Here's three major reasons why:

  * Pulling directly from translate.wordpress.org is a scaling issue.
 Simply put, GlotPress does not scale well (in general). Worse, these files
 are generated on the fly and served through PHP, which actually has the
 potential to overload our load balancers once this is in the wild. We had
 some issues with our load balancers caused by mass plugin updates just
 last month.

  * There are some major security concerns here. Basically, nearly every
 string in BuddyPress is now vulnerable to XSS, which can be exploited by a
 user getting a string approved on WordPress.org and suddenly pushed to all
 installs everywhere. Very bad. This is the number one reason why core does
 not do this yet, despite there having been a few patches for it.

  * See JJJ's point re: setting an example. As a sister project, BuddyPress
 gets (well-deserved) special treatment, but it also comes with additional
 responsibility. Likewise, while another plugin could implement this with
 their own GlotPress install, security concerns are much more sensitive
 because WordPress.org is the vector.

 So here's the good news! As JJJ said, this is coming to WordPress.org for
 ''all'' plugins by the end of June, in the form of a plugin (currently in
 development). That plugin will be included in core in 3.7 (due out later
 this summer). And we're working to create a system (and ecosystem) that
 handles all of these issues, including scaling and security. And, plugins
 will not need a single new line of code to make it work.

 While I'm here, let me provide some quick feedback on the commit anyway:

  * This results in users seeing a new update every time a string is
 approved in their language. There needs to be some throttling to the user
 experience. We are planning something a bit different for core.

  * This should actually be stored in the languages directory, not in
 uploads. And actually, BuddyPress needs to be using
 load_plugin_textdomain() here (not just because it is the right function,
 but because that's what the core implementation will hook into). '''Can
 that actually be changed for BP 1.8?'''

  * This won't work for networks that have different locales on different
 sites, which is fairly common when translations are involved. If multiple
 locales are used on the same site (such as per-user, which is also not
 uncommon on community sites), it's possible for the cron to actually stomp
 the options. We have ideas for this too.

  * The 'update check' itself also triggers a file download, even though it
 is discarded. This will have an effect on scaling WP.org, one, but it will
 also result in a slower cron, actually slowing down people's servers. This
 could even cause hosts to block traffic to translate.wordpress.org, which
 would suck especially since it'd block our translate-all-plugins effort.

  * .po should probably be downloaded as well (something we are looking
 into), as by downloading just a binary file, we actually increase security
 concerns (no way to sanity check what we just installed blindly on a
 server, and it might also scare hosts). MO files also do not have headers,
 which means we can't read headers from them (which we can with .po). Good
 when you are building something

 I should have a prototype in the next few weeks. It'll be backed by a new
 WP.org API, the code for which will most likely be public. I'll make sure
 I get you guys involved very early. This is really great, and the timeline
 for BP 1.8 final is a full month later than the time I want a beta out.

--
Ticket URL: <https://buddypress.trac.wordpress.org/ticket/4857#comment:20>
BuddyPress <http://buddypress.org/>
BuddyPress