Supporting all plugin translations?

[khromov]

As a new user, I find it confusing that this package appears to provide a Composer interface for translations via the WP translations API, yet it only includes a handful of translation packages - not very useful.

Adding custom zip sources for each plugin translation is not maintainable. What is the barrier towards allowing this repo to support all WordPress.org plugins?

[onnimonni]

Hey!

There are couple of reasons.

1. Performance issues mainly. This is a crawled static repository. There are 48,424 plugins ATM so crawling them every day would take enormous amount of time. Because this is static repository composer needs to load all of the contained information to load one package from this repo and it would be increasing the load times for current users.

2. There's no money involved. I don't need this feature so It's very unlikely for me to do this for free. If you're interested in hiring me then we can talk about the price or if you want to solve this yourself I'm more than happy to merge PR into this repo.

Instead of telling that this voluntarily maintained repository is not useful until X happens you could ask the team behind wordpress.org api to release composer compatible data so this repository wouldn't be needed anymore.

[khromov]

@onnimonni I'd be happy to take a stab at it. Currently trying to understand how the parts are fit together... Is this correct:

1. A scheduled script runs daily that connects to api.wordpress.org and checks for updates to your preselected themes/plugins, then writes them to /config/wp-packages.json
2. Another scheduled script (this time Satis) picks up the wp-packages.json file and generates the HTML page in /master branch, where it also writes the full packages.json.
3. The updating of both these scripts is handled via Travis CI?

Correct so far?

A question I had was where is the code for the script in 1. above?

As for implementing this across all packages, I've checked out the WPackagist approach, which won't work for us - they have a custom PHP Silex app that checks out every single plugin and then parses the tags, etc. We don't need this because SVN doesn't contain our data and there is an API for us to use instead.

In terms of API limits for api.wordpress.org - there doesn't seem to be any. In fact, millions of websites call this api multiple times daily, so 50k calls/day would be a drop in the ocean (about 30 requests/minute)

We will probably need a VPS to to continuously run the update checking. I'd be happy to sponsor with this and also help out with necessary code changes.

What are your thoughts @onnimonni ?

[onnimonni]

Sorry for being rude about this earlier. These issues haven't lead to any significant progress and I'm tired of people who are just asking all sorts of things without contributing anything back.

It would be really awesome to be able to load all plugin translations with composer.

I'm using the Travis CI scheduled builds to build this repository daily. It used to run in my own VPS in Digitalocean every 15 minutes but the maximum of 24h delay in Travis CI isn't that bad. Now people can see the build errors in Travis too so all of the contents of this project can be public.

So as you can see from .travis.yml you need to do following steps to build this repo:

# Install dependencies
$ composer install

# Crawl new language files from `api.wordpress.org`
$ php bin/wp-api-org

# Builds new site based on satis.json
$ php bin/satis build satis.json _site

I'm not really proud of the wp-api-org script, It was just a quick proof-of-concept hack but it has served us well.