[wp-meta] [Making WordPress.org] #760: Extract and import plugins code and readme strings to GlotPress on SVN repo actions

[Making WordPress.org]

#760: Extract and import plugins code and readme strings to GlotPress on SVN repo
actions
-----------------------+-------------------------------
  Reporter:  stephdau  |      Owner:  stephdau
      Type:  task      |     Status:  accepted
  Priority:  normal    |  Component:  Plugins Directory
Resolution:            |   Keywords:  has-patch
-----------------------+-------------------------------

Comment (by nacin):

 Replying to [comment:4 stephdau]:
 > Logic questions:
 >  * `Dotorg_Plugins_Tracker::process_i18n()` [attachment:760.diff]→L2020:
 if a plugin [https://plugins.trac.wordpress.org/browser/blogware-
 importer/trunk/readme.txt#L7 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()`
 [attachment: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,
 [https://plugins.trac.wordpress.org/browser/jetpack/trunk/languages 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.

--
Ticket URL: <https://meta.trac.wordpress.org/ticket/760#comment:6>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org