[wp-meta] [Making WordPress.org] #340: Add i18n Team Crawler Plugin to Make Polyglots
Making WordPress.org
noreply at wordpress.org
Thu Nov 27 02:36:41 UTC 2014
#340: Add i18n Team Crawler Plugin to Make Polyglots
--------------------------+-------------------------------------------
Reporter: netweb | Owner: nacin
Type: enhancement | Status: assigned
Priority: normal | Component: International Sites (Rosetta)
Resolution: | Keywords:
--------------------------+-------------------------------------------
Comment (by iandunn):
There's still more to do here, but
[https://meta.trac.wordpress.org/attachment/ticket/340/340.4.diff
340.4.diff] gets us a lot closer. Here are the highlights:
* Locale subdomains and latest releases pulled from MySQL instead of being
hardcoded and scraped from the filesystem, respectively.
* Front end always built from cached data, which gets updated via cron
every 5 minutes.
* Merged latest commits from the GitHub repo (through
[https://github.com/markoheijnen/wp-i18n-team-
crawler/commit/ab3f68514bc8eb7ae22df99c68759fe7b3621070 ab3f685]), with a
few exceptions. See below.
* Refactored HTML output into external views instead of being `echo'd` by
PHP, to improve readability.
* Modularized the locale status counts (e.g., `minor-behind`, `no-site`,
etc) for better caching and maintainability.
* Merged `inc/crawler.php` into the main class, since it only had 2
methods left in it after pulling more data from MySQL.
* Removed references to "crawler" since the wporg version isn't actually
crawling anything.
* Removed the secondary shortcode that was introduced in `340.3.diff`, so
that both views are generated by the main shortcode.
* Lots of minor tweaks.
I didn't merge the flag image on the locale details page, because it was
being pulled from a remote server that we can't trust, and which doesn't
support HTTPS, which would lead to mixed-content warnings. It also seems
wrong, since locales don't map cleanly to countries.
I also didn't merge the `Core translations` column, since I couldn't find
a good way to access the data.
* Calling `GP_Route_Locale::single()` directly in PHP would require
`include()'ing` all of GlotPress alongside WP, which seems like a recipe
for disaster.
* Requesting [https://translate.wordpress.org/api/languages/fr
https://translate.wordpress.org/api/languages/{locale}] would require a
separate call for each locale.
* Pulling directly from the database would mean duplicating a lot of the
logic from the GlotPress API.
Any ideas for a better approach? Maybe we can create a GlotPress plugin to
add the `% complete` to the https://translate.wordpress.org/api/languages
endpoint?
--
Ticket URL: <https://meta.trac.wordpress.org/ticket/340#comment:16>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org
More information about the wp-meta
mailing list