[wp-meta] [Making WordPress.org] #4752: Changelog not consistent between WordPress Admin and WP.org directory & Stable translations not updated

[Making WordPress.org]

#4752: Changelog not consistent between WordPress Admin and WP.org directory &
Stable translations not updated
------------------------------+---------------------
 Reporter:  imath             |       Owner:  (none)
     Type:  defect            |      Status:  new
 Priority:  normal            |   Milestone:
Component:  Plugin Directory  |  Resolution:
 Keywords:                    |
------------------------------+---------------------

Comment (by dd32):

 >1. I've noticed the changelog displayed within the site.url/wp-
 admin/plugins.php admin page into a Thickbox window once you click on the
 BuddyPress plugin details link wasn't consistent with the one displayed
 into the WP.org directory plugin's page.

 That appears to be caused by a caching race issue, I was able to duplicate
 it with the `en_AU` locale, it should clear up within 12-36 hrs (Sorry for
 the vagueness - caches are hard to figure out)

 It appears that this is being caused by the translation filter using a
 cache of `buddypress:stable:en_AU:changelog` and not including either
 `$stable_tag`, or an input content hash.
 The cache time here is 3 days, and it doesn't appear to get cleared by
 releasing a new plugin version.

 > 2. I know I already asked about this trouble in a previous ticket, so
 sorry to ask again, I guess I have understanding difficulties :( and I
 haven't found anything into the Plugins handbook or the Polyglots handbook
 about how to be sure strings translated into the development part of
 GlotPress are successfully replacing the one in the stable part.

 Translations are imported into GlotPress ~30 minutes after the commit
 IIRC, and that includes plugin updates - So it'll never be 100% update
 immediately, but untranslated strings should still appear and not vanish
 like happened in the above cache issue.

 It looks like part of the problem here might be that the release process
 includes a bunch of testing, rather than just releasing it and crossing
 fingers, which might be why the caches aren't as up-to-date
 Version 5.0.0's code i18n import happened Oct 2nd, 6:11pm:
 https://wordpress.slack.com/archives/C0E7F4RND/p1570003917481300
 Trunks code i18n import happened on Oct 1st, 7:21am:
 https://wordpress.slack.com/archives/C0E7F4RND/p1569878518267700

 > Currently our process is:

 Here's the ideal process:
 1. Have /trunk/ & /tags/currentTag  with `Stable Tag: currentTag`
 2. Periodically update /trunk/ with the in-process release including
 `Stable Tag: currentTag` so you get the Development updates
 3. Update /trunk/ with the new release, you can include `Stable Tag:
 newTag` - it makes not much difference at this point.
 4. {{{svn cp trunk tags/newTag}}} ({{{Stable Tag:}}} will now be useful
 and actually do something)

 Step 2 gets repeated as many times during the development cycle as you
 want, so as to get the strings up on translate.wordpress.org
 Step 3/4 only happens when making a new release.
 It looks like you've got extra steps here, because of issues you've run
 into in the past, that you shouldn't probably worry about unless it's
 actually a problem.

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