After submitting updated translatable messages of a banner, the page reloads and displays the old messages.
After reloading again, the updated messages are being displayed.
Version: unspecified
Severity: normal
Description
Description
Details
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T34482 CentralNotice should respect language fallbacks | ||
| Open | Feature | None | T38591 Use the Translate extension in CentralNotice (tracking) | ||
| Resolved | AndyRussG | T72939 CentralNotice reloads old translatable messages on form submit | |||
| Open | None | T116235 [Epic] CentralNotice translation should move closer to MediaWiki i18n standards and the code cleaned up |
Event Timeline
Comment Actions
Not sure if this is actually a code issue, or some caching on the server / syncing with translations issue, or a client browser cache issue.
Do you have a specific example where this happened (banner and language and website)?
Comment Actions
This happens on meta.wikimedia.org/wiki/Special:CentralNotice. Most probably it is a translation sync issue. I'm just editing the default language, though.
This actually happens in every case:
- Make sure you are logged in and have centralnotice adminship
- Request https://meta.wikimedia.org/wiki/Special:CentralNoticeBanners/Edit/B14_WMDE_Clone
- Change some value in the section "Translatable banner messages"
- Submit the form
- Instead of the updated value the old value is being displayed
- Reload the page
- Updated value is being displayed
Comment Actions
(In reply to Kai Nissen from comment #2)
Most probably it is a translation sync issue.
So somewhere between Language Engineering and Deployment Systems...
Comment Actions
Raising priority to normal, this is a rather annoying bug.
Pretty sure this is actually a CentralNotice issue. I noticed that the "Included templates" list doesn't update after changing the banner code either, until the page is reloaded again.
Comment Actions
Thanks!! Messages for this CentralNotice banner, currently live in Argentina, are empty... Possibly related?
Comment Actions
Change 484809 had a related patch set uploaded (by Awight; owner: Awight):
[mediawiki/extensions/CentralNotice@master] Don't use custom caching for the banner message fields
Comment Actions
Change 535133 had a related patch set uploaded (by AndyRussG; owner: AndyRussG):
[mediawiki/extensions/CentralNotice@master] In SpecialCentralNoticeBanners use $this->banner in processSaveBannerAction()
Comment Actions
Change 535133 merged by jenkins-bot:
[mediawiki/extensions/CentralNotice@master] In SpecialCentralNoticeBanners use $this->banner in processSaveBannerAction()
Comment Actions
Ooops! It looks like the attached change targeted a different bug than the one described in this change... And while it fixed the issue for me locally, it's still occurring intermittently on production and on the Beta cluster.
Here's a bug for the issue that that patch intended to fix: T232793.
Also here's an updated bug for the issue that I think this bug is about: T232430.
Thanks!!!
Comment Actions
Change 484809 abandoned by Thiemo Kreuz (WMDE):
[mediawiki/extensions/CentralNotice@master] Don't use custom caching for the banner message fields
Reason:
* Since Ibdcd41b there is a new invalidateCache() method called in a few places. I suspect this might have solved the issue.
* I also looked into the reason for the caching. The payload is not terribly expensive. All it does is a Parser::parse(). But that alone appears to be worth it. The caching was introduced via I82c8b0e in 2013. The commit message explains the reasoning in more detail.
* T72939 is marked as resolved.
Let's clean up our review queues a bit.