When opening the notifications tab, the dropdown header shows "<echo-notification-notice-text-only>" and not a more standard human-readable header. I'm guessing that a translation string is missing.
Description
Description
Related Objects
Related Objects
- Mentioned Here
- P3365 Scap issue
Event Timeline
Comment Actions
We deployed two changes for Echo:
They contain localisation change. The issue occured after we deployed them to the server through a full scap,
This scap has a failure during cache l10n step (but it's not clear if it's only for Terbium or not): P3365
Comment Actions
That was solved at 02:37 refreshing the ResourceLoader caches through a l10nupdate manual run.
Relevant server admin log's entries
02:37 logmsgbot: l10nupdate@tin ResourceLoader cache refresh completed at Fri Jul 8 02:37:29 UTC 2016 (duration 6m 22s)
02:31 logmsgbot: dereckson@tin scap sync-l10n completed (1.28.0-wmf.9) (duration: 07m 47s)
02:12 Dereckson: scap pull on terbium (was out of disk space during previous full scap)
02:00 logmsgbot: l10nupdate@tin LocalisationUpdate failed: git pull of extensions failed
01:54 mutante: terbium ran out of disk, deleted rotated nutcracker log
01:48 logmsgbot: dereckson@tin Finished scap: Flow 297914, Echo 297919 297934, ORES 297916 (duration: 27m 48s)
[…]
01:20 logmsgbot: dereckson@tin Started scap: Flow 297914, Echo 297919 297934, ORES 297916
Note for the future
A full scap could be enough (but that's untested). We were here after the Thursday last part of the MediaWiki train, with only one MW version in use. When there are several versions in use, l10nupdate is A LOT slower than a full scap. If all worked fine excepted the l10n step, scap sync-l10n could even be enough.
02:53:00 < Krinkle> Yeah, running full scap will rebuild l10n cache files, sync them as part of the sync, and purge caches presumably
02:55:52 < Krinkle> Yes, 'scap sync', just like 'scap sync-l10n' calls update_localization_cache() which uses rebuildLocalisationCache.php which will purge MessageBlobStore for all wikis