WordPress.org

Making WordPress.org

Opened 6 years ago

Last modified 5 years ago

#760 closed task

Plugins directory internationalization project — at Version 18

Reported by: stephdau Owned by: stephdau
Milestone: Priority: normal
Component: Plugin Directory Keywords: has-patch
Cc:

Description (last modified by stephdau)

Update: description below is for the original scope of the ticket ("Extract and import plugins code and readme strings to GlotPress on SVN repo actions"). We're now using the same ticket for the whole project ("Plugins directory internationalization project"), in an effort to keep things in one place.


The attached patches introduce new methods to achieve the task in the existing SVN tracker code.

Processing:

  • Dotorg_Plugins_Tracker::process_i18n( $slug, $branch = 'dev', $type = 'all' )
  • Dotorg_Plugins_Tracker::process_code_i18n( $path_rel, $branch = 'dev' )
  • Dotorg_Plugins_Tracker::process_readme_i18n( $path_rel, $branch = 'dev' )


Helpers:

  • Dotorg_Plugins_Tracker::handle_translator_comment( $array, $key, $val )
  • Dotorg_Plugins_Tracker::import_to_glotpress_project( $project, $branch, $file )

The methods can be called from within the class, externally, or be run from the CLI as:

cd ./plugins/

# processes both code and readme in dev/trunk
php bb-load.php i18n blogware-importer

# processes code only, in stable branch
php bb-load.php i18n blogware-importer stable code

# processes readme only, in dev
php bb-load.php i18n blogware-importer dev readme

Notes:

Left:

  • Need list of plugins we want to start with, since we decided to start with a finite number. Note: this might be better off being decided in private, asked Nacin
  • Need to define when/where to trigger the code/readme i18n reruns exactly (have options, need to pick with sys/perf in mind)
  • Logic to create GP projects on the fly for new and existing plugins, thing we can leave for the next cycle since only dealing with a set list of plugins at first.

Change History (27)

@stephdau
6 years ago

#1 @stephdau
6 years ago

  • Description modified (diff)
  • Owner set to stephdau
  • Status changed from new to accepted

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

#3 @stephdau
6 years ago

  • Description modified (diff)

#4 follow-up: @stephdau
6 years ago

Logic questions:

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

#6 in reply to: ↑ 4 @nacin
6 years ago

Replying to stephdau:

Logic questions:

  • Dotorg_Plugins_Tracker::process_i18n() 760.diff→L2020: if a plugin lists its stable tag as trunk, the patch uses the dev and dev-readme instance of the related GP project, so translators do not need to needlessly maintain 2 "sets" (dev vs stable). Is that the right way to go?

Yes.

  • Dotorg_Plugins_Tracker::process_code_i18n() 760.diff→L2061: I have logic to use a plugin's own POT file, instead of generating a temporary one ourselves, if committed in the repo as {$slug}/{$slug}.pot or {$slug}/languages/{$slug}.pot. Is that also the right way to go?

Hmm. Not sure. I would say no.

  • Dotorg_Plugins_Tracker::process_code_i18n(): should we also have logic to use a plugin's own committed PO/MO files if any, like Jetpack? What if they don't have a committed POT file, and ours somehow doesn't match their PO/MO files (doubtful but possible)?

Nope, I don't think so. These will override language packs, but the goal should be to import them into GP and remove them from the plugin.

#7 @stephdau
6 years ago

  1. Excellent
  2. Cool
  3. Sounds fair. We can do that manually for the initial short list, and work on longer-term automation afterward, along with the does-project-exist-create-if-not parts.

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

@stephdau
6 years ago

Implements feedback so far, and introduces some experimental display related methods

#9 @stephdau
6 years ago

760.2.diff Implements feedback so far, and introduces some experimental display related methods:

  • Dotorg_Plugins_Tracker::translate()
  • related Dotorg_Plugins_Tracker::_*_gp_*() helpers
  • Dotorg_Plugins_Tracker::localize_section_url()

There's no caching or anything, but the queries are based on indices, and the code is "functional" to showcase how things will work.

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

@stephdau
6 years ago

Follow up on 760.2.diff: refactors code into own file/class for cleanliness, adds full caching (see 760-translate.diff for cache handling), adds translation support in search results and listings, improves all code.

@stephdau
6 years ago

Adds translation support to api.wordpress.org, once 760-wporg.diff is in place

@stephdau
6 years ago

GlotPress plugin for translate.wordpress.org to clear/delete the transaltion cache keys used in the localized plugins directories and api upon interaction with GP (imports, translation edits, etc).

#11 @stephdau
6 years ago

When combined together, the latest patches bring the entire solution to life (albeit still experimental)! Consider it a complete proof-of-concept of the whole plugins directories internationalization project. :D

See https://cloudup.com/cmAHT9qu2Wx

  • 760-wporg.diff: handles code and readme translation processing (CLI and automated in Dotorg_Plugins_Tracker::save_data()), as well as localized directories caching and display
  • 760-api.diff: handles api.wordpress.org translation when a (temp/dev) language param is passed
  • 760-translate.diff: handles clearing the translation cache keys used in the localized plugins directories and api upon interaction with GP (imports, translation edits, etc).
Last edited 6 years ago by stephdau (previous) (diff)

@stephdau
6 years ago

#12 @stephdau
6 years ago

760-wporg.2.diff:

  • Dotorg_Plugin_I18n::import_to_glotpress_project() now also sets some GlotPress string priorities.
    • https://cloudup.com/cYTSZvl3bi0
    • plugin name & short description (both used the most): high prio (1)
    • changelog items: low prio (-1)
    • everything else: normal prio (0)
    • treating description items as standard prio so the important strings are not lost in a sea of high prio ones for readmes with long descriptions.
  • No longer processes the license string from the readme, as being in the WP Plugin Directory implies GPLv2 or later. No need for everybody translating that in every plugin.
  • Misc code cleanups (method renaming, etc).
Last edited 6 years ago by stephdau (previous) (diff)

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

@stephdau
6 years ago

#14 @stephdau
6 years ago

760-wporg.3.diff improves on the exisitng code, as well as adds translate/bin/set-wp-plugin-project.php, which is used by Dotorg_Plugin_I18n::process() to initialize the GlotPress environment required for the targeted plugin.

php translate/bin/set-wp-plugin-project.php livejournal-importer

@stephdau
6 years ago

#15 @stephdau
6 years ago

760-wporg.4.diff:

  • adds support for both short and long locale/language slugs (fr vs fr_FR, for eg).
  • handles $_REQUESTrequest?->locale for api.wordpress.org queries.
  • adds and uses Dotorg_Plugin_I18n::verify_subdomain() for localized sites (fr.wordpress.org, etc)
  • misc improvements over 760-wporg.3.diff

#16 @stephdau
6 years ago

760-translate.2.diff makes sure that GP_WPorg_Plugins::delete_plugin_i18n_cache_keys_for() deals with cache keys for both a short and long versions of a locale (eg: fr vs fr_FR), as keys might exist under either.

This ticket was mentioned in Slack in #meta-i18n by stephdau. View the logs.


6 years ago

#18 @stephdau
6 years ago

  • Description modified (diff)
  • Summary changed from Extract and import plugins code and readme strings to GlotPress on SVN repo actions to Plugins directory internationalization project
Note: See TracTickets for help on using tickets.