Changelog not consistent between WordPress Admin and WP.org directory & Stable translations not updated

[imath]

Hi,

Since this commit ​2166042 for the BuddyPress 5.0.0 upgrade:

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. See the screen capture below.

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. As it has failed once again (see screen capture below), I guess I did something wrong again.

We wrote a process to publish a new tag on the plugins repository of BuddyPress. As I've followed it, I think it would save us time if I could update the process with what has to be done to be 100% sure we are not doing it wrong.

Currently our process is:

• update trunk with new tag
• edit stable tag in trunk/readme.txt to previous version (to check everything went well once the tag is created)
• svn cp trunk tags/tag
• edit stable tag in tags/tag/readme.txt to the new version
• commit
• download and test the tag
• edit stable tag in trunk/readme.txt to the new version
• commit.

Thanks in advance for your help.

[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.

[ocean90]

I have manually imported 5.0.0 so that the stable project (​https://translate.wordpress.org/projects/wp-plugins/buddypress/stable/) now has the strings from the 5.0.0 tag. That import has also cleared any caches.

As mentioned by Dion, the process has too many steps causing the sync issues. The code for handling what and when gets imported can be reviewed at https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/jobs/class-plugin-i18n-import.php?rev=6287&marks=77-92#L67.
When only the readme gets updated (your second last step) only the readme gets imported.

[imath]

Thanks a lot for your help @dd32 & @ocean90

I confirm it's now fixed. I will update our upgrade process according to your recommandations.

[dd32]

Replying to dd32:

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.

Replying to ocean90:

I have manually imported ... That import has also cleared any caches.

Unfortunately it doesn't look like the GlotPress side of things clears all caches, as there's double caching on the plugin directory side.
In addition to caching the originals/translations, there's also text-chunk caching of the_content strings - https://meta.trac.wordpress.org/browser/sites/trunk/wordpress.org/public_html/wp-content/plugins/plugin-directory/class-plugin-i18n.php?marks=387-392,426#L334

I'm not sure if that caching is actually needed, but I don't really want to remove it entirely incase it is, I think reducing it to a 5 or 15 minute cache would be plenty though

[ocean90]

Replying to dd32:

Unfortunately it doesn't look like the GlotPress side of things clears all caches, as there's double caching on the plugin directory side.

I think we're talking about the same caches, since there's no other caching I'm aware of. Cache_Purger is responsible for clearing the linked "text-chunk caching".