[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